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Abstract of FR2794918 

the system includes modification of header 
routing information during transfer of packets. 
The procedure provides processing for data 
packets in a communication network 
comprises two end bridges separated by at 
least one intermediate bridge. The packet 
includes an information field of predetermined 
length reserved for routing information. The 
procedure includes receiving the data packet 
at an intermediate bridge, called a relay 
bridge, and removing routing information 
relating to the route already passed by the 
packet. With the use of an index this routing 
information may be recovered and the routing 
information restored for onward transmission 
of the packet. 
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(57) L'invention est relative a un procede de traitement 
(fun paquet de donnees dans un reseau de communication 
comportant deux ponts dits d'extremites separes I'un de 
I'autre par au moins un pont dit intermediaire, chacun des- 
dits ponts interconnectant au moins deux parties dudit re- 
seau, ledit paquet comportant au moins un champ 
d' informations de longueur predeterminee reserve a des in- 
formations d'identification d'un chemin dans le reseau, ca- 
racterise en ce que ledit procede comporte les etapes 
suivantes: 

- recevoir ledit paquet de donnees par un pont interme- 
diaire appele pont relais et au niveau duquel le champ d'in- 
formations d'identification du chemin parcouru par ledit 
paquet contient un nombre maximum d'informations d'iden- 
tification dudit chemin et/ ou le champ d'informations d'iden- 
tification du chemin a parcourir par ledit paquet est vide, 

- faire intervenir, d'une part, une premiere zone memoire 
(1265; 1314) dans ledit pont relais et qui comporte un 
champ d'informations d'identification d'un chemin entre ledit 
pont relais et un autre pont et, d'autre part, au moins un in- 
dex (b1 , f1 ) dans le paquet de donnees et qui permet de re- 
trouver ladite zone memoire dans ledit pont relais. 
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10 La presente invention concerne un precede et un dispositif de 

traitement d'un paquet de donnees dans un reseau de communication 
comportant deux ponts dits d'extremites separes i'un de I'autre par au moins un 
pont dit intermediate, chacun desdits ponts interconnectant au moins deux 
parties dudit reseau, ledit paquet comportant au moins un champ d'informations 
15 de longueur predeterminee reserve a des informations d'identification d'un 
chemin dans le reseau. 

On connaTt des reseaux de communication qui sont formes de 
plusieurs bus de communication serie conformes a la norme IEEE 1394. 

Ces bus sont organises en reseau, c'est-a-dire qu'ils sont relics 
20 entre eux par des equipements ou ensembles d'equipements que Ton nomme 
des "ponts" ("bridges" en terminoiogie anglo-saxonne). 

Un pont permet de transferer des paquets de donnees d'une 
premiere partie du reseau ou premier sous-reseau vers une deuxieme partie du 
reseau ou deuxieme sous-reseau par liaison filaire, optique, radio ou par tout 
25 autre type de liaison physique envisageable. 

Une partie d'un reseau est egalement appelee sous-reseau. 

Les ponts reliant entre eux des bus de communication serie font 
plus particulierement I'objet de la norme P1 394.1 qui est en cours de 
discussion. 

30 Dans le cadre de cette norme, un pont comporte plus 

particulierement au moins deux equipements d'interconnexion appeles "portals" 
en terminoiogie anglo-saxonne et permettant de relier entre eux au moins deux 
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bus de communication serie 1394. Un equipement d'interconnexion ou "portal" 
est un ensemble de ports conformes a la norme 1394 et connectes a un bus de 
communication serie 1394. 

Chaque bus de communication serie d'un tel reseau relie 
5 differents equipements ou peripheriques entre eux tels que des imprimantes, 
ordinateurs, serveurs, scanners, magnetoscopes, decodeurs (connus en 
terminologie anglo-saxonne sous le terme de "set top box"), televiseurs, 
cameras numeriques, camescopes, appareils photographiques numeriques... 
Ces peripheriques sont egalement appeles nceuds. 
10 Chaque equipement ou peripherique situe sur un bus du reseau 

peur vouloir communiquer des informations a un autre equipement du reseau 
situe sur un autre bus du reseau, les deux bus sur lesquels ces equipements sont 
situes etant separes par un ou plusieurs ponts. 

Ainsi, chacun de ces ponts sera done amene a transferer de 
15 maniere selective ou non les informations echangees entre les deux 
peripheriques depuis I'un des bus connecte a I'un des equipements 
d'interconnexion ou "portals" dudit pont vers un autre bus dispose de I'autre 
cote dudit pont et connecte a un autre equipement d'interconnexion ou "portal" 
de ce meme pont. 

20 Chaque bus peut §tre connecte a plusieurs autres bus par 

I'intermediaire de plusieurs ponts differents. 

Lorsqu'un equipement d'interconnexion ou "portal" regoit un 
paquet de donnees il doit done pouvoir identifier si le paquet qu'il regoit est 
destine a un peripherique present sur son bus ou a un ou plusieurs des 

25 equipements d'interconnexion ou "portals" presents sur son bus. 

Pour ce faire, les informations vehiculees sur les differents bus du 
chemin que parcourt le paquet de donnees doivent indiquer la destination du 
paquet et chaque equipement d'interconnexion ou "portal" doit etre capable 
d'analyser cette destination pour transmettre les informations au peripherique 

30 destinataire. 

Dans les reseaux conformes a la norme IEEE-1394, I'adresse de 
la destination est codee dans I'en-tete du paquet de donnees dans un premier 
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champ conformations de longueur fixe et dit d'identification, appele champ 
destination, et I'adresse de la source dudit paquet de donnees est codee dans 
un deuxieme champ d'informations de I'en-tete, dit d'identification et de 
longueur fixe, appele champ source. Ces deux champs sont distincts et leur 
5 longueur depend du protocole de communication. 

Dans les reseaux conformes a la norme IEEE-1394, le champ 
destination est par exemple code sur 16 bits et le champ source egalement. 
Ces 16 bits sont separes en 10 bits reserves au codage de I'identificateur du 
bus sur lequel se trouve le peripherique destinataire du paquet de donnees et 6 
10 bits reserves au codage de I'identificateur du peripherique destinataire sur ce 
bus. 

De tels reseaux de transfert de paquets de donnees necessitent . 
un equipement centralise (connu sous le terme "prime portal" en terminologie 
anglo-saxonne) qui, lors de I'initialisation du reseau, va attribuer un numeYo a 
15 chaque bus du reseau. Ensuite, apres cette etape de numeYotation 
automatique, chaque equipement d'interconnexion ou "portal" de chaque pont 
va configurer une table de routage qui lui est propre en fonction des differents 
messages qu'il aura vu passer. 

Cette table de routage est par exemple representee par une 
20 succession de bits ou chaque bit correspond a un bus du reseau. 

Chaque bit sera positionne a la valeur binaire 0 ou 1 , 0 si le pont 
ne doit pas transferer des donnees destinees a un peripherique present sur le 
bus correspondant a ce bit dans la table, et 1 si le pont doit transferer des 
donnees destin6es a un peripherique present sur le bus correspondant a ce bit 
25 dans la table. 

Ces reseaux sont configures pour pouvoir interconnecter un 
nombre maximal de 1024 bus. Chaque table de routage doit done comporter 
1023 bits et chaque pont doit done comporter deux tables de routage de 1023 
bits puisque chaque portal est relie a des bus differents et doit done, de ce fait, 
30 posseder sa propre table. 

Dans un tel reseau, lorsque le paquet de donnees arrive dans le 
pont, celui-ci lit le champ destination place dans I'en-tete de ce paquet de 
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donnees et lit sa table de routage afin de determiner s'il peut transmettre le 
paquet au bus destinataire, c'est-a-dire si le bit correspondant a ce bus est 
positionn§ a "1" dans la table de routage. 

On connaTt des precedes de transfert de paquets de donnees tels 
5 que celui decrit dans le brevet US 5 442 881 , permettant de coder I'en-tete a la 
source. Le peripherique ou noeud source qui veut emettre un paquet de 
donnees connaTt le chemin qui le separe du peripherique destinataire auquel il 
veut transferer des donnees. Ce chemin est code dans un champ de I'en-tete 
du paquet de donnees qui comporte toutes les adresses ou identifications des 
10 differents noeuds du reseau rencontres par ledit paquet de donnees sur son 
chemin. 

Lorsqu'un equipement de ce reseau, charge du transfert des 
paquets, recoit le paquet de donnees, il decode cet en-tete et transmet le 
paquet au peripherique destinataire apres avoir modifie cet en-tete. 

15 On connaTt egalement le brevet US 5 613 069 qui decrit un 

precede de transfert de paquets dans un reseau a commutation de paquets, 
chaque paquet comprenant un champ d'en-tete de longueur variable pour 
decrire le chemin a parcourir ainsi qu'un champ de fin de paquet de longueur 
variable pour decrire le chemin parcouru. 

20 Toutefois, ce systeme s'applique a la commutation de paquets ou 

chaque port d'un commutateur est relie a un seul autre port d'un autre 
commutateur alors qu'un pont peut etre relie a plusieurs autres ponts via un 
mSme bus. 

Ainsi, une telle solution n'est pas adaptee a etre mise en ceuvre 
25 dans un reseau du type de ceux presentes ci-dessus, conformes a la norme 
IEEE 1394. Dans ces reseaux, I'en-tete de chaque paquet de donnees 
comporte un champ destination et un champ source, dont 10 bits seulement 
sont reserves dans chacun d'eux au codage de I'identificateur du bus sur lequel 
se trouve le peripherique destinataire ou source. 
30 En effet, dans un reseau du type conforme a la norme IEEE 1394, 

dans le cas ou le nombre maximal autorise de chaque equipement 
d'interconnexion ou "portal" d'un pont sur un bus est de trois, il faut deux bits 
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pour coder I'adresse ou I'identificateur de chaque equipement d'interconnexion 
ou "portal" de facon unique. 

Le champ destination de I'en-tete des paquets de donnees peut 
done contenir en theorie quatre identificateurs d'equipements d'interconnexion 
5 ou "portals" differents. 

Le nombre maximal theorique de ponts separant la source et la 
destination est done, dans cet exemple, de quatre. 

Ceci est restrictif et Ton constate que plus le nombre 
d'equipements d'interconnexion ou "portals" autorises sur un bus augmente, 

10 plus il est necessaire d'avoir un nombre eleve de bits pour coder I'identificateur 
de ces equipements d'interconnexion ou "portals" et done plus la distance 
maximale entre la source d'un paquet de donnees et sa destination est faible. 

D'une maniere generate, il serait par consequent interessant de 
pouvoir augmenter la distance entre la source et la destination d'un paquet de 

15 donnees lorsque le champ dudit paquet qui est reserve a I'identification du 
chemin de ce paquet dans le reseau a une taille limitee. 

La presente invention vise ainsi a remedier a ce probleme en 
proposant un precede de traitement d'un paquet de donnees dans un reseau de 
communication comportant deux ponts dits d'extremites separes I'un de I'autre 

20 par au moins un pont dit intermediate, chacun desdits ponts interconnectant au 
moins deux parties dudit reseau, led it paquet comportant au moins un champ 
d'informations de longueur predeterminee reserve a des informations 
d'identification d'un chemin dans le reseau, caracterise en ce que ledit precede 
comporte les etapes suivantes : 

25 - recevoir ledit paquet de donnees par un pont intermediaire 

appele pont relais et au niveau duquel le champ d'informations d'identification 
du chemin parcouru par ledit paquet contient un nombre maximum 
d'informations d'identification dudit chemin et/ou le champ d'informations 
d'identification du chemin a parcourir par ledit paquet est vide, 

30 - faire intervenir, d'une part, une premiere zone memoire dans ledit 

pont relais et qui comporte un champ d'informations d'identification d'un chemin 
entre ledit pont relais et un autre pont et, d'autre part, au moins un index dans 
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le paquet de donnees et qui permet de retrouver ladite zone memoire dans ledit 
pont relais. 

Correlativement, I'invention vise un dispositif de traitement d'un 
paquet de donnees dans un reseau de communication comportant deux ponts 
5 dits d'extremites s6pares I'un de I'autre par au moins un pont dit intermediaire, 
chacun desdits ponts interconnectant au moins deux parties dudit reseau, ledit 
paquet comportant au moins un champ d'informations de longueur 
predeterminee reserve a des informations d'identification d'un chemin dans le 
reseau, caracterise en ce que ledit dispositif comporte les etapes suivantes : 

10 -recevoir ledit paquet de donnees par un pont intermediaire 

appele pont relais et au niveau duquel le champ d'informations d'identification 
du chemin parcouru par ledit paquet contient un nombre maximum 
d'informations d'identification dudit chemin et/ou le champ d'informations 
d'identification du chemin a parcourir par ledit paquet est vide, 

15 -faire intervenir, d'une part, une premiere zone memoire dans 

ledit pont relais et qui comporte un champ d'informations d'identification d'un 
chemin entre ledit pont relais et un autre pont et, d'autre part, au moins un 
index b1 ,f1 dans le paquet de donnees et qui permet de retrouver ladite zone 
m6moire dans ledit pont relais. 

20 II convient de noter qu'un pont relais est defini differemment selon 

que le paquet est un paquet de diffusion, un paquet de reponse a un paquet de 
diffusion ou bien un paquet asynchrone. 

En effet, si le paquet est un paquet de diffusion alors il n'existe 
pas encore de chemin etabli pour le paquet et un pont relais est defini comme 

25 etant un pont au niveau duquel le chemin parcouru par ledit paquet contient un 
nombre maximum d'informations d'identification dudit chemin. 

Ceci signifie soit que le chemin parcouru par le paquet, lorsque ce 
dernier est arrive au niveau du pont considere, occupe en totalite la longueur 
predetermined du champ d'informations d'identification, soit que I'espace 

30 restant disponible dans ledit champ pour coder un nouvel identificateur de 
routage d'un pont n'est plus suffisant. 
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En revanche, si le paquet est un paquet de reponse a un paquet 
de diffusion ou bien un paquet asynchrone, il existe un chemin etabli (au moins 
dans un sens du parcours) pour le paquet dans le reseau et un pont relais est 
alors defini comme etant un pont au niveau duquel le chemin a parcourir par 
5 ledit paquet est vide. 

Par ailleurs, le stockage et la gestion des index et des zones 
memoires referencees par ces index sont effectues au niveau des ponts relais 
et ne sont done pas centralises. 

Ceci permet notamment de repartir dans tous les ponts relais la 
10 capacite memoire necessaire. 

L'invention permet d'augmenter la distance entre la source et la 
destination d'un paquet de donnees. 

En outre, cet avantage est egalement obtenu independamment du 
nombre de ponts connectes a chaque partie du reseau, chaque partie etant par 
1 5 exemple un bus de communication. 

Selon un premier mode de realisation de l'invention, le precede 
comporte les etapes suivantes : 

- allocation de ladite zone memoire et recuperation dudit index b1 , 
-ecriture dans ladite zone m6moire des informations 

20 d'identification du chemin parcouru par le paquet depuis I'autre pont jusqu'audit 
pont relais , 

- ecriture dudit index dans le paquet. 

Selon une caracteristique, le precede comporte une etape 
d'ecriture dans ladite zone memoire d'un autre index bO permettant de 
25 retrouver ulterieurement dans I'autre pont appele egalement pont relais une 
zone memoire comportant des informations d'identification du chemin parcouru 
par le paquet pour parvenir jusqu'a cet autre pont relais . 

Selon une caracteristique, le precede comporte une etape 
d'utiiisation de I'index b1 ecrit dans le paquet pour retrouver dans ledit pont 
30 relais les informations d'identification du chemin a parcourir par ledit paquet 
depuis ledit pont relais jusqu'a I'autre pont . 
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Selon une caracteristique, I'etape d'utilisation de I'index b1 ecrit 
dans le paquet permet egalement de retrouver I'index bO qui sera utilise 
ulterieurement dans I'autre pont pour retrouver la zone memoire comportant 
des informations d'identification du chemin a parcourir a partir de cet autre pont. 
5 Selon une caracteristique, le procede comporte une etape 

d'ecriture de I'index bO dans le paquet a la place de I'index b1 . 

Selon une caracteristique, le procede comporte une etape 
d'ecriture, dans le paquet, d'informations d'identification du chemin a parcourir a 
la place d'informations d'identification du chemin parcouru. 
10 Selon une caracteristique, le procede comporte les etapes suivantes : 

- allocation d'une deuxieme zone memoire dans ledit pont relais 
reference par un autre index f2 donne, 

-ecriture dans ladite deuxieme zone memoire d'informations 
d'identification du chemin parcouru par le paquet depuis I'autre pont jusqu'audit 
15 pont relais, 

- ecriture dudit index f2 dans le paquet. 

Selon un deuxieme mode de realisation, le procede comporte une 
etape d'ecriture dans la deuxieme zone memoire du pont relais d'un index b2 
permettant de retrouver ulterieurement dans I'autre pont une zone memoire 
20 comportant des informations d'identification du chemin parcouru par le paquet 
depuis ledit pont relais jusqu'audit autre pont . 

Selon une caracteristique, le procede comporte une etape 
d'utilisation de I'index f1 ecrit dans le paquet pour retrouver dans la zone 
memoire dudit pont relais les informations d'identification du chemin a parcourir 
25 depuis ledit pont relais jusqu'a un autre pont. 

Selon une autre caracteristique, I'etape d'utilisation de I'index f1 
ecrit dans le paquet permet egalement de retrouver un deuxieme index f2 qui 
sera utilise ulterieurement dans I'autre pont appele pont relais pour retrouver 
une zone memoire comportant des informations d'identification du chemin a 
30 parcourir a partir de cet autre pont relais. 

Selon une caracteristique, le procede comporte une etape 
d'ecriture de I'index f2 dans le paquet a la place de I'index ft. 
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Selon une caracteristique, ledit paquet de donn6es comporte au 
moins deux champs d'informations dits d'identification du chemin 
respectivement a parcourir et parcouru par ledit paquet de donnees, lesdits au 
moins deux champs d'informations ayant chacun une longueur donnee, ledit 
5 precede comportant les etapes suivantes lors du transfert dudit paquet de 
donnees a travers un pont : 

- suppression d'au moins une premiere information d'au moins un 
premier champ d'informations, r6duisant ainsi la longueur dudit premier champ 
d'informations d'une longueur correspondant a celle de ladite premiere 

10 information, 

- ajout d'au moins une deuxieme information dans au moins un 
deuxieme champ d'informations, augmentant ainsi la longueur- dudit deuxieme 
champ d'informations d'une longueur correspondant a celle de ladite deuxieme 
information. 

15 Selon une caracteristique particuliere, le dispositif de traitement 

selon I'invention comporte une zone memoire referencee par un index et 
comportant, d'une part, des informations d'identification du chemin parcouru par 
le paquet depuis I'autre pont jusqu'audit pont relais et, d'autre part, un index 
permettant de retrouver ult6rieurement dans ledit autre pont une zone m6moire 

20 comportant des informations d'identification du chemin parcouru par le paquet 
pour parvenir jusqu'a cet autre pont. 

Selon une autre caracteristique particuliere, le dispositif de 
traitement selon I'invention comporte une zone memoire referenced par un 
index comportant, d'une part, des informations d'identification du chemin a 

25 parcourir parle paquet depuis ledit pont relais jusqu'a I'autre pont et, d'autre 
part, un index permettant de retrouver ulterieurement dans cet autre pont des 
informations d'identification du chemin a parcourir par le paquet depuis cet 
autre pont jusqu'a un deuxieme autre pont. 

Selon un deuxieme aspect, I'invention vise un procede d'emission 

30 d'un paquet de donnees dans un r6seau de communication entre deux ponts 
dits d'extremites separes I'un de I'autre par plusieurs ponts dits interm&Jiaires, 
chacun desdits ponts interconnectant au moins deux parties dudit reseau, ledit 
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paquet comportant au moins un champ conformations de longueur 
predeterminee reserve a des informations d'identification d'un chemin dans le 
reseau, caracterise en ce que ledit precede comporte une etape d'emission 
dudit paquet de donnees a partir d'un premier pont d'extremite, ledit au moins 
5 un champ contenant des informations d'identification du chemin a parcourir 
depuis ledit premier pont d'extremite jusqu'a un pont intermediaire appele pont 
relais et au niveau duquel le champ d'informations d'identification du chemin 
parcouru par ledit paquet contient un nombre maximum d'informations 
d'identification dudit chemin et/ou le champ d'informations d'identification du 

10 chemin a parcourir par ledit paquet est vide, ledit paquet de donnees 
comportant egalement un index permettant de retrouver au niveau dudit pont 
relais des informations representatives du chemin a parcourir depuis ledit pont 
relais jusqu'au deuxieme pont d'extremite. 

Correlativement, I'invention vise un dispositif d'emission d'un 

15 paquet de donnees dans un reseau de communication entre deux ponts dits 
d'extremites separes I'un de I'autre par plusieurs ponts dits intermediaires, 
chacun desdits ponts interconnectant au moins deux parties dudit r6seau, ledit 
paquet comportant au moins un champ d'informations de longueur 
predeterminee reserve a des informations d'identification d'un chemin dans le 

20 reseau, caracterise en ce que ledit dispositif comporte des moyens d'emission 
dudit paquet de donnees a partir d'un premier pont d'extremite, ledit au moins 
un champ contenant des informations d'identification du chemin a parcourir 
depuis ledit premier pont d'extremite jusqu'a un pont intermediaire appel6 pont 
relais et au niveau duquel le champ d'informations d'identification du chemin 

25 parcouru contient un nombre maximum d'informations d'identification dudit 
chemin et/ou le champ d'informations d'identification du chemin a parcourir est 
vide, ledit paquet de donnees comportant egalement un index permettant de 
retrouver au niveau dudit pont relais des informations representatives du 
chemin a parcourir depuis ledit pont relais jusqu'au deuxieme pont d'extremite. 

30 Selon un troisieme aspect, I'invention vise un procede de 

reception d'un paquet de donnees emis sur un reseau de communication entre 
deux ponts dits d'extremites separes I'un de I'autre par plusieurs ponts dits 
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intermediates, chacun desdits ponts interconnectant au moins deux parties 
dudit reseau, ledit paquet comportant au moins un champ d'informations de 
longueur predetermined reserve a des informations d'identification d'un chemin 
dans le reseau, caracterise en ce que ledit precede comporte une etape de 
5 reception au niveau d'un premier pont d'extremite dudit paquet de donn6es 
emis par un deuxieme pont d'extremite, ledit au moins un champ contenant des 
informations d'identification du chemin parcouru depuis un pont intermediate 
appeie pont relais et au niveau duquel le champ d'informations d'identification 
du chemin parcouru par ledit paquet contient un nombre maximum 

10 d'informations d'identification dudit chemin et/ou le champ d'informations 
d'identification du chemin a parcourir par ledit paquet est vide, ledit paquet 
comportant egalement un index permettant de retrouver. au niveau dudit pont 
relais des informations representatives du chemin parcouru depuis le deuxieme 
pont jusqu'audit pont relais. 

15 Correlativement, I'invention vise un dispositif de reception d'un 

paquet de donnees 6mis sur un reseau de communication entre deux ponts dits 
d'extremites s§pares I'un de I'autre par plusieurs ponts dits intermediaires, 
chacun desdits ponts interconnectant au moins deux parties dudit reseau, ledit 
paquet comportant au moins un champ d'informations de longueur 

20 predeterminee reserve a des informations d'identification d'un chemin dans le 
reseau, caracterise en ce que ledit dispositif comporte des moyens de reception 
au niveau d'un premier pont d'extremite dudit paquet de donnees emis par un 
deuxieme pont d'extremite, ledit au moins un champ contenant des informations 
d'identification du chemin parcouru depuis un pont intermediaire appeie pont 

25 relais et au niveau duquel le champ d'informations d'identification du chemin 
parcouru contient un nombre maximum d'informations d'identification dudit 
chemin et/ou le champ d'informations d'identification du chemin a parcourir est 
vide, ledit paquet comportant egalement un index permettant de retrouver au 
niveau dudit pont relais des informations representatives du chemin parcouru 

30 depuis le deuxieme pont jusqu'audit pont relais. 

Selon un quatrieme aspect, I'invention vise un pont relais d'un 
reseau de communication dispose entre deux ponts dits d'extr6mites et 
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interconnectant au moins deux parties dudit reseau de communication, 
caracterise en ce que ledit pont comporte un dispositif de traitement d'un 
paquet de donnees conforme a ce qui precede. 

Selon un cinquieme aspect, I'invention vise un pont d'extremite 
5 d'un reseau de communication interconnectant au moins deux parties dudit 
reseau de communication, caracterisS en ce qu'il comporte un dispositif 
d'emission et/ou un dispositif de reception d'un paquet de donn6es comme. 
expose ci-dessus. 

Selon un sixieme aspect, I'invention vise un appareil de traitement 
10 de donnees, caracteris6 en ce qu'il comporte un dispositif de traitement d'un 
paquet de donnees conforme au bref expos6 qui precede. 

Selon un septieme aspect, I'invention. vise un appareil de 
traitement de donnees, caracteris6 en ce qu'il comporte un dispositif d'emission 
et/ou un dispositif de reception d'un paquet de donnees comme expose ci- 
15 dessus. 

Selon un huitieme aspect, I'invention vise un appareil de. 
traitement de donnees, caracterise en ce qu'il comporte un pont conforme a ce 
qui precede. 

L'appareil de traitement est, par exemple, une imprimante. 
20 L'appareil de traitement est, par exemple, un serveur. 

L'appareil de traitement est, par exemple, un ordinateur. 

L'appareil de traitement est, par exemple, un telecopieur. 

L'appareil de traitement est, par exemple, un scanner. 

L'appareil de traitement est, par exemple, un magnetoscope. 
25 L'appareil de traitement est, par exemple, un decodeur (connu en 

terminologie anglo-saxonne sous le terme de "set top box"). 

L'appareil de traitement est, par exemple, un teleViseur. 

L'appareil de traitement est, par exemple, un camescope. 

L'appareil de traitement est, par exemple, une camera num6rique. 
30 L'appareil de traitement est, par exemple, un appareil 

photographique numerique. 
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Selon un neuvieme aspect, I'invention vise un reseau de 
communication comportant au moins deux parties interconnectees par au 
moins un pont, caracteris6 en ce que ledit pont est conforme a ce qui precede. 

Selon un dixieme aspect, I'invention vise un r6seau de 
5 communication, caracterise en ce qu'il comporte un appareil de traitement de 
donnees tel qu'expose ci-dessous. 

L'invention vise par ailleurs un moyen de stockage d'informatjons, 
eventuellement totalement ou partiellement amovible, lisible par un ordinateur 
ou un processeur contenant des instructions d'un programme informatique, 
10 caracteris6 en ce qu'il permet la mise en ceuvre du procede de traitement et/ou 
d'emission et/ou de reception d'un paquet de donnees tel que brievement 
expose ci-dessus. 

L'invention vise en outre un moyen de stockage d'informations, 
eventuellement totalement ou partiellement amovible, lisible par un ordinateur 
15 ou un processeur contenant des donnees provenant de la mise en ceuvre du 
procede de traitement et/ou d'emission et/ou de reception d'un paquet de 
donnees tel que brievement expose ci-dessus. 

L'invention vise egaiement une interface permettant de recevoir 
les instructions d'un programme informatique, caracterise en ce qu'il permet la 
20 mise en ceuvre du procede de traitement et/ou d'emission et/ou de reception 
d'un paquet de donnees tel que brievement expose ci-dessus. 

L'invention vise en outre un signal comportant des instructions 
utilisables par un ordinateur et adaptees a configurer un dispositif 
programmable en un dispositif de traitement et/ou d'emission et/ou de reception 
25 d'un paquet de donnees tel qu'expose ci-dessus. 

L'invention vise par ailleurs un signal comportant des instructions 
utilisables par un ordinateur et adaptees a faire fonctionner un dispositif 
programmable pour mettre en ceuvre un procede de traitement et/ou d'emission 
et/ou de reception d'un paquet de donnees tel qu'expose ci-dessus. 
30 Les avantages et caracteristiques propres aux precedes et 

dispositifs d'emission et de reception, au dispositif de traitement d'un paquet de 
donnees, au pont interconnectant au moins deux parties d'un reseau et 
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comportant de tels dispositifs, a I'appareil de traitement de donnees comportant 
de tels dispositifs, audit reseau comportant un tel pont et audit reseau 
comportant un tel appareil de traitement de donnees, ainsi qu'aux moyens de 
stockage d'informations etant les memes que ceux exposes ci-dessus 
5 concemant le precede de traitement d'un paquet de donnees selon I'inyention, 
ils ne seront pas rappeles ici. 



10 



D'autres caracteristiques et avantages apparaTtront au cours de la 
description qui va suivre donnee a titre d'exemple illustratif et non limitatif, et 
1 5 faite en reference aux dessins annexes sur lesquels : 

- la figure 1 est une vue schematique d'un reseau de bus de 
communication serie ; 

- la figure 2 est une vue schematique representant la structure 
d'un paquet de donnees asynchrone tel que defini dans la norme IEEE 1394- 

20 95; 

- la figure 3 est une vue schematique detaillee d'un appareil de 
traitement de donnees comportant un pont reference 66 sur la figure 1 ; 

- la figure 4 est une vue schematique representant differents 
registres stockes dans la memoire RAM de I'appareil de traitement de donnees 

25 de la figure 3 ; 

- la figure 5 est une vue schematique illustrant le transfe'rt d'un 
paquet de donnees a travers le pont intermediate reference 66 la figure 1 "; 

- la figure 6 est une vue schematique illustrant le transfert d'un 
paquet de donnees a travers le pont destinataire reference 67 sur la figure 1 ; 

30 - la figure 7 est une vue schematique illustrant le transfert d'un 

paquet de donnees a travers le pont source reference 67 sur la figure 1 ; 
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- la figure 8 est une vue schematique detaillee representant line 
table de routage stockee dans la memoire RAM de I'appareil de traitement de 
donnees de la figure 3 ; 

- les figures 9 et 10 represented une vue schematique des 
5 algorithmes des precedes, d'une part, de recuperation d'un descripteur de 

chemin a partir d'un index dans la table de routage et, d'autre part, de 
recuperation d'un index a partir d'un descripteur de chemin ; 

- la figure 11 est une vue schematique de I'algorithme d'un 
precede de transfert de paquets ; 

10 - la figure 12 est une vue schematique d'un reseau de bus lors de 

la diffusion d'un paquet de resolution d'adresse d'une part, et de son paquet 
reponse correspondant d'autre part ; 

- la figure 13 est une vue schematique representant la structure 
d'un paquet de donnees de resolution d'adresse ; 

15 - la figure 14 est une vue schematique representant la structure 

d'un paquet de donnees asynchrone de reponse au paquet decrit en figure 13 ; 

- la figure 15 est une vue schematique detaillee representant une 
table de verification stockee dans la memoire RAM de la figure 3 ; 

- la figure 16 est une vue schematique de I'algorithme d'un 
20 precede de reception d'un paquet de resolution d'adresse au niveau d'un 

equipement d'interconnexion d'un pont ; 

- la figure 17 est une vue schematique de I'algorithme d'un 
precede de reception d'un paquet de donnees de reponse au paquet de 
resolution d'adresse au niveau d'un equipement d'interconnexion d'un pont ; 

25 - la figure 1 8 est une vue schematique de I'algorithme d'un precede 

de gestion de la longueur des identificateurs ou labels de routage au niveau 
d'un bus en fonction de la capacite du bus ; 

- la figure 19 est une vue schematique de I'algorithme d'un 
precede de gestion de la longueur des identificateurs ou labels de routage au 

30 niveau d'un bus en fonction du nombre de ponts connectes sur le bus, 

- la figure 20 est une vue schematique representant un reseau de 
communication selon I'invention, 



16 



2794918 



- la figure 21 iilustre de maniere schematique le cheminement d'un 
paquet de resolution d'adresse dans le reseau de communication represente a 
la figure 1 , 

- la figure 22 represente un algorithme sur lequel est base le 
5 precede de traitement d'un paquet de donnees selon I'invention et qui est mis 

en ceuvre au niveau d'un pont intermediate du reseau represente a la figure 
20, 

- la figure 23 iilustre de maniere schematique le cheminement d'un 
paquet de reponse au paquet de resolution d'adresse represents a la figure 21 

1 0 a travers le reseau de la figure 20, 

- la figure 24 represente un algorithme sur lequel est base le 
procede de traitement d'un paquet de donnees selon I'invention et qui est mis 
en ceuvre au niveau d'un pont du reseau de communication represents a la 
figure 20, 

15 - la figure 25 iilustre de maniere schematique le cheminement d'un 

paquet de requete asynchrone a travers le reseau de communication de la 
figure 20, 

- la figure 26 represente un algorithme sur lequel est bas£ le 
procede de traitement d'un paquet de donnees asynchrone selon I'invention et 

20 qui est mis en ceuvre au niveau d'un pont du reseau de communication de la 
figure 20, 

- la figure 27 iilustre de maniere schematique le cheminement d'un 
paquet de reponse asynchrone a travers le reseau de communication de la 
figure 20. 

25 La figure 1 represente une vue schematique d'un reseau de bus 

de communication se>ie dans le cadre duquel s'applique I'invention. Un 
ensemble de bus de communication serie 51, 52, 53, 54, 55, 56, 57, 58 et 59, 
interconnected par plusieurs ponts 60, 61, 62, 63, 64, 65, 66 et 67, permettent a 
des peripheriques situes sur des bus differents d'echanger des paquets de 

30 donnees asynchrones. 

Ainsi, un pSripherique 68, connecte au bus 52, peut initier une 
transaction avec un peripherique 69 qui, lui, se trouve connecte au bus 59, par 
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echanges de paquets asynchrones. Le transfert de paquets d'un bus a I'autre 
est assure par un precede de transfert de paquets. 

La structure d'un paquet asynchrone, largement decrite dans la 
norme IEEE 1394-95, est illustree a la figure 2. Les paquets asynchrones sont 
5 entre autre utilises pour effectuer des transactions entre un peripherique source 
et un peripherique destination. Une transaction est effectuee en emettant un 
paquet de type "Requete" de la source vers la destination, puis un paquet de 
type "Reponse" de la destination vers la source. 

Le champ "destinationJD" 80 de la figure 2 ("Destination 
10 Identifier" en terminologie anglo-saxonne), represente sur 16 bits, contient 
Tinformation de routage permettant d'atteindre le peripherique destination. Ce 
champ est compose de deux sous, champs 80a "destination_Bus_ID" 
represente sur 10 bits et 80b "destination_Node_ID" represente sur 6 bits. 

Le champ 80a est appele champ d'identification du chemin a 
1 5 parcourir par le paquet de donnees. 

Le champ "sourceJD" 81 ("Source Identifier" en terminologie 
anglo-saxonne), represente sur 16 bits, contient ('information de routage 
permettant d'atteindre le peripherique source. Ce champ est compose de deux 
sous champs 81a "source_Bus_ID" represente sur 10 bits et 81b 
20 "source_Node_ID" represente sur 6 bits. 

Le champ 81a est appele champ d'identification du chemin 
parcouru par le paquet de donnees. 

La presence de ces deux champs 80 et 81 favorise le deroulement 
d'une transaction entre la source et la destination. 
25 II convient' de noter que les deux champs d'informations 

d'identification d'un paquet de donnees ne sont pas necessairement places 
dans I'en-tete dudit paquet, comme c'est la cas dans cet exemple, mais peuvent 
etre situes a Pextremite opposee de ce paquet, c'est-a-dire en fin de paquet. 

Le champ "tl" 82 ("Transaction Label" en terminologie anglo- 
30 saxonne), represente sur 6 bits, permet de numeroter une transaction entre des 
p6ripheriques. 
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Le champ "rt" 83 ("Retry Code" en terminologie anglo-saxonne), 
represents sur 2 bits, permet d'identifier les tentatives d'emission d'un mSme 
paquet asynchrone. 

Le champ "tcode" 84 ('Transaction Code" en terminologie anglo- 
5 saxonne), represents sur 4 bits, permet d'identifier un type de paquet 
asynchrone, tel que par exemple le type de la transaction. 

Le champ "pri" 85 ("Priority" en terminologie anglo-saxonne), 
represents sur 4 bits, permet d'identifier la priorite associee au paquet 
asynchrone. 

10 Les champs 86, 87, 88, 89 et 90 sont pour certains optionnels et 

sont relatifs a Interpretation des donnees vehiculees par le paquet asynchrone. 

La figure 3 represente la structure schematique d'un appareil de 
traitement de donnees tel qu'un ordinateur 1 1 comportant, par exemple, le pont 
66 represente a la figure 1. Ainsi, tous les ponts du reseau represented a la 

15 figure 1 ont par exemple cette structure. 

L'appareil de traitement de donnees pourrait egalement prendre la 
forme d'une imprimante, d'un serveur, d'un telecopieur, d'un scanner, d'un 
magnetoscope, d'un decodeur (connu en terminologie anglo-saxonne sous le 
terme de "set top box"), d'un televiseur, d'un camescope, d'une camSra 

20 numerique ou d'un appareil photographique numerique. 

Tous les ponts de la figure 1 peuvent etre par exemple etre 
integrSs dans un appareil de traitement de donnees de ce type ou bien 
constituer l'appareil lui-m§me. 

Le pont constitue, dans cet exemple, un dispositif de transfert de 

25 paquets. Ce pont comporte une unite de calcul CPU 12, une memoire de 
stockage permanent 14 (ROM) qui contient les differentes" instructions des 
algorithmes reprSsentes aux figures 9, 10, 11, 16, 17, 18, 19, 23, 24 et une 
memoire de stockage temporaire 16 (RAM). Ces trois elements 12, 14 et 16 
communiquent au moyen de bus d'adresses et de donnees respectifs notes 18, 

30 20, 22, avec un bloc note 24 et connu de I'homme de I'art sous le nom de pont 
PCI. 
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L'ordinateur 1 1 comporte egalement un ecran 13, un clavier 15, un 
lecteur de disquettes 17, un lecteur de CD-ROM 19 et une interface reseau 21 
(figure 3). 

L'interface reseau 21 peut recevoir, par exemple, par 
5 I'intermediaire d'un reseau local (non represente) de type Ethernet les 
instructions d'un programme informatique permettant la mise en ceuvre du 
precede selon I'invention. 

De telles instructions peuvent egalement etre contenues dans le 
lecteur de disquettes ou le lecteur de CD-ROM. 

10 Le bloc 24 est en fait un ensemble de composants PCI tel que 

I'ensemble Intel 440LX AGP ("Intel 440LX AGPset" dans la terminologie anglo- 
saxonne) commercialise par la societe INTEL. Ainsi, le bloc 24 comporte, par 
exemple, un composant 82443LX (non represente) qui assure l'interface avec 
la memoire 16 via le bus memoire 22 et avec I'unite de calcul CPU 12 via le bus 

15 local 18. Le composant 82443LX est lui-meme relie a un composant 82371 AB 
(non represente) qui foumit une interface avec le bus ISA 20 relie a la memoire 
14 et aux differentes extensions de peripheriques : 6cran 13, clavier 15, lecteur 
de disquette 17, lecteur de CD-ROM 19 et interface de reseau 21. Un 
controleur d'interruption IOAPIC Intel 82093AA (non represente) connecte a 

20 I'unite de calcul CPU 12 gere les interruptions pouvant survenir dans le 
systeme. 

Ce bloc 24 permet notamment d'echanger des donn6es au moyen 
du bus standard PCI 26 (PCI signifiant en terminologie anglo-saxonne 
"Peripheral Component Interconnect") avec un autre composant d'interface PCI 

25 note 28. Le bus 26 peut egalement connecter entre eux d'autres elements, non 
represents sur la figure, eux-memes pourvus d'une interface PCI et pouvant 
mettre en ceuvre par exemple des fonctions de traitement de donnees. 

Le composant 28 est un composant denomme AMCC5933QC et 
est commercialise par la societe Applied Micro Circuits Corporation. 

30 II convient de noter que le dispositif de transfer! de paquets ne 

correspond pas necessairement au pont lui-meme. II peut ainsi, en effet, en 
representer un sous-ensemble forme, par exemple, des differents elements 
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permettant de mettre en ceuvre les fonctions de traitement de I'en-tete d'un 
paquet de donnees, de prise en compte d'au moins un identificateur de pont, et 
de transfert de paquets asynchrones. 

Les fonctions de traitement d'en-tete sont mises en ceuvre par 
5 I'unite de calcul CPU 12 et les memoires ROM 14 et RAM. 16. 

La fonction de transfert d'un paquet asynchrone apres traitement 
de I'en-tete est mise en ceuvre par un bloc logique de controle 34 et des 
composants 30, 32 surordre de I'unite de calcul CPU 12. 

Le pont 66 represents a la figure 3 comporte egalement deux 
1 0 ensembles de composants appeles aussi blocs 30 et 32 servant respectivement 
d'interfaces avec les bus de communication serie 1394, par exemple notes 56 
et 58 sur la figure 1. Chaque bloc ou ensemble de composants PHY/LINK 1394 
est par exemple constitue d'un composant PHY TSB21LV03A et d'un 
composant LINK TSB12LV01A commercialises par la soci6te Texas 
15 Instruments et de connecteurs 1394, par exemple commercialises par la 
societe Molex, par exemple sous la reference 53462. 

Le pont 66 comporte deux equipements d'interconnexion du pont 
qui ferment chacun ce que Ton appelle un "portal" en terminologie anglo- 
saxonne. 

20 Sur la figure 3 les elements du pont qui sont references 

12,14,16,18,20,22,24,26,28,34,36,38,40,42 et 44 sont communs a chacun des 
equipements d'interconnexion ou "portals" de ce pont et seuls les blocs de 
composants PHYLINK 1394 notes 30 et 32 sont specifiques respectivement a 
chaque equipement d'interconnexion. 

25 Toutefois, dans certains cas les equipements d'interconnexion ou 

"portals" d'un pont sont physiquement eloignes (cas d'une liaison radio) et les 
autres elements enonces ci-dessus sont alors propres a chacun des 
equipements d'interconnexion. 

Le bloc logique de controle note 34 peut respectivement 

30 communiquer avec les blocs de composants 30 et 32 au moyen de bus notes 
36 et 38, ainsi qu'avec le composant d'interface PCI 28 au moyen d'un bus 40. 
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Des bus 42 et 44 permettent egalement les transferts de donnees 
respectivement entre le composant d'interface PCI 28 et le bloc logique de 
controle 34, ainsi que le bloc de composants PHY/LINK 1394 reference 30, 
d'une part, et, d'autre part, avec le bloc de controle logique 34 et le bloc de 
5 composants PHY/LINK 1394 reference 32. 

Ce bloc logique de contr6le 34 permet de transmettre des paquets 
de donnees isochrones ou asynchrones venant du bus de communication serie 
56 par I'intermediaire du bloc de composants PHY/LINK 1394 note 30 qui lui est 
associe et a destination de la mSmoire RAM 1 6, sous le controle de la fonction 

10 m6moire a acces direct DMA ("Direct Memory Access" en terminologie anglo- 
saxonne) qui se trouve dans le composant d'interface PCI 28 et qui aura et§ 
prealablement initialisee par I'unite de calcul CPU 1 2. 

Inversement, ce bloc 34 permet egalement de transmettre des 
paquets de donnees isochrones ou asynchrones provenant de la meYnoire 16 

15 vers I'autre bloc PHY/LINK 1394 note 32, en vue de sa transmission sur le bus 
de communication serie qui lui est associe. Ceci a egalement lieu sous le 
controle de la fonction memoire a acces direct DMA mentionne ci-dessus. 

Le bloc logique de controle 34 permet en outre de declencher une 
interruption PCI par exemple liee a la reception ou a remission d'un paquet 

20 asynchrone par I'intermediaire du composant d'interface PCI 28 afin d'informer 
I'unite de calcul CPU 12. De la meme maniere, le bloc logique de controle 34 
est susceptible de generer une interruption PCI pour d'autres types 
d'ev6nements tels que la reception ou remission de tout autre paquet de 
donnees surun bus 1394. 

25 En outre, le bloc logique 34 permet d'acceder aux differents 

registres des blocs de composants 30 et 32 via le composant d'interface PCI 
28. 

Le bloc logique de controle 34 est un composant de type FPGA 
("Field Programmable Gate Array" en terminologie anglo-saxonne) qui est par 
30 exemple commercialism par la soctete Xilinx. 
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A chaque bloc de composants 30 et 32 sont associSs des 
registres reprSsentSs a la figure 4, utilises pour la mise en oeuvre du procSdS 
de transfert de paquets de donnees. 

Dans la description qui suit, un registre dont le nom est suffixS par 
5 "_30" ou "_32" appartient aux blocs respectifs 30 et 32 dScrits precSdemment 
en reference a la figure 3. 

Un registre 91 dSnommS "routing_label_30", reprSsentS sur 8 bits, 
contient un identificateur ou adresse de routage qui identifie les paquets qui 
devront etre transfSrSs du bus 56 vers le bus 58 dans I'exemple du pont 66. 
10 Un registre 92 dSnommS "routing_width_30", reprSsentS sur 8 

bits, est associS au registre 91 et indique le nombre de bits significatifs du 
registre 91 . Les registres 91 et 92 sont associSs au bloc de composants 30. 

Un registre 93 dSnommS "routing_label_32", represents sur 8 bits, 
contient un identificateur ou adresse de routage qui identifie les paquets qui 
1 5 devront etre transferes du bus 58 vers le bus 56 dans I'exemple du pont 66. 

Un registre 94 dSnommS "routing_width_32", represents sur 8 
bits, est associS au registre 93 et indique le nombre de bits significatifs du 
registre 93. Les registres 93 et 94 sont associSs au bloc de composants 32. 

Un registre 97 denomme "max_width", represents par exemple 
20 sur 32 bits, contient la valeur maximale que peuvent prendre les registres 92 et 
94. Ce registre n'est done pas associS a un equipement d'interconnexion ou 
"portal" en particulier. A un instant donne, il contient la meme valeur dans 
chaque pont du rSseau considers. 

Dans le mode prSfSrS de rSalisation, la valeur des registres 92, 94 
25 et 97 est prSdSterminSe et Sgale a "3" pour chaque registre. 

Parmi I'ensemble des Squipements d'interconnexion ou "portals" 
connectes a un meme bus 1394 la norme P1 394.1 prSvoit la dStermination d'un 
Squipement d'interconnexion particulier appelS "alpha-portal". 

Les moyens de dStermination de "I'alpha-portal" sont connus et 
30 notamment dScrits dans le chapitre 4.1 du projet de norme P 1394.1 version 
0.04, du 7 FSvrier 1999. Ces moyens permettent notamment d'identifier de 
maniere constante et unique les peripheriques d'un meme bus. Par extension 
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ces moyens permettent aussi d'affecter de la m6me maniere un identificateur 
ou label de routage constant et unique a chaque equipement d'interconnexion 
ou "portal" d'un meme bus. 

II convient de noter que chaque Equipement (periph6rique, 
5 equipement d'interconnexion...) relie a un bus est repere par un identificateur 
dit physique et par un identificateur dit virtuel. 

La correspondance entre I'identificateur physique et I'identificateur 
virtuel d'un equipement est etablie dans une table de correspondance telle que 
celle representee a la figure 21 et sur laquelle on reviendra plus en detail 
10 ulterieurement. 

La valeur de I'identificateur virtuel d'un equipement connecte a un 
bus reste constante m§me si la topologie liee a ce bus est modifiee. 

Ainsi, vues de I'exterieur du bus, les valeurs des identificateurs 
virtuels ne changent pas malgre une modification de la topologie du bus 
1 5 considere. 

Par ailleurs, les equipements d'interconnexion relies a un bus 
possedent egalement I'identificateur de routage mentionne ci-dessus. 

Un identificateur de routage ainsi determine, par exemple pour 
I'equipement d'interconnexion du pont 66 qui est relie au bus 56, est stocke 

20 dans le registre 91 et identifie I'equipement d'interconnexion ou "portal" 
contenant le bloc 30 de la figure 3. De m§me, un identificateur de routage ainsi 
determine, par exemple pour I'equipement d'interconnexion du pont 66 qui est 
relie au bus 58, est stocke dans le registre 93 et identifie I'equipement 
d'interconnexion ou "portal" contenant le bloc 32 de la figure 3. 

25 Un registre 95 denomme "routing_table_30" sur la figure 4, 

represents sur 960 bits, represente une table de routage associee a 
I'equipement d'interconnexion ou "portal" contenant le bloc 30 et est utilise lors 
du transfert de paquets £mis depuis le bus 56, en ce qui concerne le pont 66. 

Un registre 96 denomme "routing_table_32", represente sur 960 

30 bits, represente une table de routage associee a I'equipement d'interconnexion 
ou "portal" contenant le bloc 32 et est utilise lors du transfert de paquets emis 
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depuis le bus 58, en ce qui concerne le pont 66. La structure de cette table de 
routage est decrite en detail a la figure 8. 

5 Un registre 98 denomme "portal_numbering_30" sur la figure 4 

comporte, d'une part, au moins une table de correspondance dont la structure 
sera decrite ulterieurement en reference a la figure 21 et qui est associ6e a 
I'equipement d'interconnexion ou "portal" contenant le bloc 30. 

10 Un registre 99 denomme "portal_numbering_32" sur la figure 4 

comporte, d'une part, au moins une table de correspondance dont la structure 
sera decrite ulterieurement en reference a la figure 21 et qui est associee a 
I'equipement d'interconnexion ou "portal" contenant le bloc 32. 

15 Les registres 91, 92, 93, 94, 95, 96, 97, 98 et 99 repr6sentes a la 

figure 4, sont situes dans la memoire RAM 16 du pont 66 represents a la figure 
3. 

Un paquet asynchrone, emis par un p6ripherique source situe sur 
un bus different de celui sur lequel est situe le peripherique destinataire, est dit 
20 paquet asynchrone "distant", par opposition a un paquet asynchrone local. 

En outre, lorsqu'un paquet asynchrone "distant" transite, par 
exemple depuis le peripherique 68 (figure 1) jusqu'au peripherique 69, via les 
ponts 61, 62, 64, 66 et 67, differents traitements sont appliques par chacun de 
ces ponts en fonction de leur position relative par rapport au peripherique 
25 source et au peripherique destinataire. 

Ainsi, lorsqu'aucun des equipements d'interconnexion ou "portals" 
d'un pont considere n'est connecte ni au bus du peripherique source, ni au bus 
du peripherique destinataire, le pont est dit pont "intermediaire". C'est le cas du 
pont 66 lorsque, par exemple, le peripherique 68 transmet un paquet 
30 asynchrone au peripherique 69. 

La figure 5 illustre de maniere schematique le traitement, 
qu'effectue le pont 66 en tant que pont "intermediaire", sur les champs 80 et 81 
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du paquet asynchrone qu'il transfere depuis le bus 56 vers le bus 58, selon le 
sens indique par la fleche 219. 

Le registre 76 est I'equivalent du registre 91 represents a la figure 
4 et a, par exemple, pour valeur "001" en representation binaire sur 3 bits 
5 significatifs. 

En outre, le registre 77 est I'equivalent du registre 93 represents a 
la figure 4, et a, par exemple, pour valeur "01 1" en representation binaire sur 3 
bits significatifs. 

On va maintenant s'interesser, en reference aux figures 5 et 6, au 
10 transfert d'un paquet asynchrone de donnees note 199 du bus 56 au 
peripherique 69 du bus 59. 

Le paquet asynchrone de donnees 199 transite sur le bus 56 et 
est transfere au bus 58, par le pont 66, apres traitement, sous la forme d'un 
paquet 216. Les paquets asynchrones 199 et 216 sont conformes a la structure 
15 de paquet representee a la figure 2 et ne different I'un de I'autre que par le 
contenu de leurs champs respectifs destination 80 et source 81. 

Le champ 80 du paquet 199 est decompose en plusieurs champs 
notes 200, 201, 202 et 203. Le champ 81 du paquet 199 est lui aussi 
decompose en plusieurs champs notes 204, 205, 206, 207 et 208. 
20 Les champs 201 et 202, tous les deux representes sur 3 bits, 

contiennent les identificateurs de routage des equipements d'interconnexion ou 
"portals" a prendre en compte respectivement par les ponts 66 et 67 pour 
transferer le paquet asynchrone jusqu'au peripherique destinataire 69. 

Les champs 208, 207 et 206, representes chacun sur 3 bits, 
25 contiennent les identificateurs de routage des equipements d'interconnexion ou 
"portals" a prendre en compte respectivement par les ponts 64, 62 et 61 pour 
transferer un paquet asynchrone en retour jusqu'au peripherique source 68. 

Le champ 203, represents sur 6 bits, contient I'information qui 
permet au pont 67 d'identifier le peripherique destinataire 69 du paquet 
30 asynchrone parmi tous les peripheriques du bus 59. De maniere generate, il 
s'agit du champ 80b "destination_Node_ID" de la figure 2. 
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Le champ 204, represente sur 6 bits, contient I'information qui 
permet au pont 61 d'identifier le peripherique source 68 du paquet asynchrone 
parmi tous les pSripheriques du bus 52. De maniere generate, il s'agit du champ 
81b "source_Node_!D" de la figure 2. 
5 Les champs 200 et 205 dont I'ensemble est represente sur 5 bits 

qui sont tous positionnes a "1", contiennent un marqueur delimitant les champs 
202 et 201 , d'une part, des champs 208, 207 et 206, d'autre part. 

Les champs 201 et 202 ferment ce que I'on appelle un premier 
champ d'informations et identified le chemin qui est a parcourir par le paquet 
10 dedonnees 199. 

Les champs 206, 207 et 208 ferment ce que Ton appelle un 
deuxieme champ d'informations et identified le chemin deja parcouru par le 
paquet de donnees 199. 

Les champs 200 et 205 ferment ce que Ton appelle un troisieme 
1 5 champ d'informations ou marqueur. 

Dans le cas du paquet 216 issu du pont 66, le champ 80 
comprend les champs 209, 210, 211 et 203 et le champ 81 comprend les 
champs 212, 213, 214, 215 et 204. 

Le champ 211, represente sur 3 bits, contient I'identificateur de 
20 routage a prendre en compte par le pont 67 pour transferer le paquet 
asynchrone jusqu'au peripherique destinataire 69. II correspond au champ 201 
du paquet 199. 

Les champs 215, 214 et 213, representes chacun sur 3 bits, ainsi 
que les champs 209 et 212, dont I'ensemble est represente sur 3 bits, 

25 contiennent les identificateurs de routage a prendre en compte respectivement 
par les ponts 66, 64, 62 et 61, pour transferer le paquet asynchrone, en retour, 
jusqu'au peripherique source 68. Les champs 213 et 214 correspondent 
respectivement aux champs 207 et 208 du paquet 199. Les champs 209 et 212 
correspondent au champ 206 du paquet 199. 

30 Le champ 210, represente sur 5 bits, qui sont tous positionnes a 

"1", contient le marqueur delimitant le champ 211, d'une part, des champs 209 
a 215, d'autre part. II correspond aux champs 205 et 200 du paquet 199. 
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A la reception du paquet 199, le pont 66 lit et analyse la valeur du 
champ 202 qu'il compare avec le contenu du registre 76. Puisque les deux 
valeurs, exprimees sur le meme nombre de bits significatifs, sont identiques, le 
paquet 199 va etre transfere du bus 56 au bus 58 sous la forme du paquet 216. 
5 On notera qu'entre le paquet 199 et le paquet 216, le pont 66 a, 

d'une part, supprime du premier champ d'informations une premiere information 
constitute par les bits "001" appartenant au champ 202 et, d'autre part, ajoute 
au deuxieme champ d'informations une deuxieme information constitute par les 
bits "011" du registre 77 d'identification de I'equipement d'interconnexion ou 

10 "portal" considere. 

Sur la figure 5, il convient de noter que, d'une part, la suppression 
d'une premiere information (champ 202) du premier champ d'informations reduit - 
la longueur de ce dernier et, d'autre part, I'ajout d'une deuxieme information 
(champ 215) dans le deuxieme champ d'informations augmente la longueur de 

1 5 ce dernier. 

Cette deuxieme information est representee par le champ 215. 

Le precede de transfert de paquets procede egalement, apres la 
suppression de la premiere information et avant I'ajout de la deuxieme 
information, au decalage des premier, deuxieme et troisieme champs 
20 d'informations a I'interieur des sous-champs 80a et 81a des champs 80 et 81. 

Lorsque I'un des 6quipements d'interconnexion ou "portals" d'un 
pont est connecte au bus du periphtrique destinataire, le pont est dit pont 
"destination". C'est le cas par exemple du pont 67 de la figure 1 lorsque le 
peripherique 69 regoit un paquet asynchrone distant en provenance du 
25 peripherique 68. 

La figure 6 illustre de maniere schematique le traitement, 
qu'effectue le pont 67 en tant que pont "destination", sur les champs 80 et 81 
du paquet asynchrone 216 qu'il transfere depuis le bus 58 vers le bus 59, selon 
le sens indique par la fleche 229. 
30 Le registre 78 illustre, pour le pont 67, le registre 91 represents a 

la figure 4 et dont la valeur, sur 3 bits significatifs, est "011" en representation 
binaire. Par ailleurs, le registre 79 illustre, pour le pont 67, un registre 93 
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represents figure 4 et dont la valeur, sur 3 bits significatifs, est "000" en 
representation binaire. 

Le paquet asynchrone 216 qui transite sur le bus 58, est transmis 
sur le bus 59, par le pont 67 apres traitement, sous la forme d'un paquet 226. 
5 Les paquets asynchrones 216 et 226 sont conformes a la structure de paquet 
representee a la figure 2 et ne different Tun de I'autre que par le contenu de 
leurs champs respectifs 80 et 81 . 

Dans le cas du paquet 226, le champ 80 est decompose en 
plusieurs champs 220 et 221 et le champ 81 est lui aussi decompose en 
1 0 plusieurs champs 223, 224 et 204. 

Le champ 220, represents sur 10 bits qui sont tous positionnes a 
"1", est representatif d'un paquet asynchrone destine au bus local et . 
susceptible d'etre recu par I'un des peripheriques du bus 59. 

Le champ denomme "offset" et note 223 est ajoute par le pont 67 
15 alors que le champ 224 contient I'identificateur de routage ou adresse de 
I'equipement d'interconnexion ou "portal" du pont 67 associe au bus 59 et 
stocke dans le registre 79. 

A la reception du paquet 216, le pont 67 lit et analyse la valeur du 
champ 211 qu'il compare avec le contenu du registre 78. Puisque les deux 
20 valeurs, exprimees sur le mSme nombre de bits significatifs, sont identiques, le 
paquet 216 va etre transfere du bus 58 au bus 59 sous la forme du paquet 226. 

Lors du transfert du paquet 216 a travers le pont 67, ce dernier a 
supprime d'un premier champ d'informations qui est forme du champ 21 1 , une 
premiere information constitute par les bits "011 " du champ 21 1 iui-meme. 
25 Ce premier champ d'informations identifie le chemin restant a 

parcourir au paquet 216 pour parvenir a destination. 

Le pont 67 a ensuite sauvegarde dans la table de routage 
associee a I'equipement d'interconnexion ou "portal" comprenant le registre 79 
un deuxieme champ d'informations qui est form6 de I'ensemble des champs 
30 209,212, 213, 214 et 215. 
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Ce deuxieme champ d'informations identifie le chemin parcouru 
par le paquet 216 et ce sera le chemin dit de "retour" qui lui permettra, 
eventuellement, d'etre renvoye au peripherique source. 

Le pont 67 a ensuite renseigne ce deuxieme champ d'informations 
5 alors forme par le champs 224, une deuxieme information constituee par les 
bits "000" du registre 79 d'identification de l'6quipement d'interconnexion ou 
"portal" consider^. 

Le troisieme champ d'informations correspond au marqueur note 
210 et precedemment evoque. 
1 0 Le precede de transfert de paquets procede egalement, apres la 

suppression de la premiere information et avant I'ajout de la deuxieme 
information, a la sauvegarde du deuxieme champ d'information, au stockage de 
I'index de cette sauvegarde dans le champ 223 et a la mise a "1" de tous les 
bits du champ 220.. 

15 Le champ 203, represent6 sur 6 bits, permet au pont "destination" 

67, d'identifier le peripherique destinataire 69 du paquet asynchrone parmi tous 
les peripheriques du bus 59. Le champ 203 du paquet 216 a ete remplace, lors 
du transfert dans le pont 67, par le champ 221 dans le paquet 226. Le champ 
221 identifie, par exemple, le peripherique 69 parmi tous les peripheriques du 

20 bus 59, afin que le paquet 226 soit regu par le peripherique 69. Le champ 203 
contient I'identificateur virtuel du peripherique 69 alors que le champ 221 
contient I'identificateur physique du pe>iph£rique 69 

Le champ 204, represente sur 6 bits, contient I'information qui 
permet au pont 61 d'identifier le peripherique source 68 emetteur du paquet 

25 asynchrone parmi tous les peripheriques du bus 52. Le champ 204 est 
representatif de I'identificateur virtuel du peripherique 68. 

Lorsque I'un des equipements d'interconnexion ou "portals" d'un 
pont est connecte au bus du peripherique source le pont est dit pont "source". 
C'est le cas par exemple du pont 67 de la figure 1 lorsque le peripherique 69 

30 transmet un paquet asynchrone "distant" a destination du peripherique 68, par 
exemple en reponse au paquet 226. 
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La figure 7 illustre de maniere schematique les modifications 
effectives par le pont 67 en tant que pont "source", sur les champs 80 et 81 
d'un paquet asynchrone qu'il transfere depuis le bus 59 vers le bus 58, selon le 
sens indique par la fleche 230. 
5 Le paquet asynchrone 231 6mis sur le bus 59 par le periphSrique 

69 est transfere sur le bus 58, par le pont 67, apres traitement, sous la forme 
d'un paquet 240. Les paquets asynchrones 231 et 240 sont conformes a la 
structure de paquet representee a la figure 2 et ne different I'un de I'autre que 
par le contenu de leurs champs respectifs 80 et 81 . 

10 Dans le cas du paquet 231, le champ destination 80 est 

decompose en plusieurs champs 232, 233 et 234 et le champ source 81 est 
egalement decompose en plusieurs champs 235 et 236. 

Le champ denomme "offset" et note 232 est utilise par le pont 67 
pour retrouver I'ensemble des identificateurs de routage a prendre en compte, 

15 respectivement par les ponts 66, 64, 62 et 61, pour transferer le paquet 
asynchrone jusqu'au peripherique destinataire 68. Le champ 233 contient 
I'identificateur de routage du pont 67 associe au bus 59 et stocke dans le 
registre 79. 

Le champ 236, represents sur 10 bits, qui sont tous positionnes a 
20 "1 ", est reprSsentatif d'un paquet asynchrone emis par le bus local. 

Dans le cas du paquet 240, le champ destination 80 est 
decompose en plusieurs champs 241, 242, 243, 244 et 234 et le champ source 
81 est egalement decompose en plusieurs champs 246, 247, 248 et 249. 

Les champs 244, 243 et 242, representes chacun sur 3 bits, ainsi 
25 que les champs 241 et 246, dont I'ensemble est represents sur 3 bits, 
contiennent les identificateurs de routage ou adresses des equipements 
d'interconnexion ou "portals" a prendre en compte respectivement par les ponts 
66, 64, 62 et 61, pour transferer le paquet asynchrone jusqu'au p6riph6rique 
destination 68. 

30 Le champ 248, represents sur 3 bits, contient I'identificateur de 

routage a prendre en compte par le pont 67 pour transferer en retour le paquet 
asynchrone jusqu'au peripherique source 69. 
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Le champ 247, repr6sente sur 5 bits et dont tous les bits sont 
positionn6s a "1", contient un marqueur delimitant les champs 241 a 244, 234 et 
246, d'une part, du champ 248, d'autre part. 

A la reception du paquet 231 , le pont 67 lit et analyse la valeur du 
5 champ 233 qu'il compare avec le contenu du registre 79. Puisque les deux 
valeurs, exprim6es sur le meme nombre de bits significatifs, sont identiques, le 
paquet 231 va etre transfer^ du bus 59 au bus 58 sous la forme du paquet 240. 

On notera que dans le paquet 240, les identificateurs de routage 

241, 242, 243, 244 et 246 representatifs du chemin a parcourir jusqu'au 
1 0 peripherique destination 68 et le champ 248 representatif du chemin parcouru 

depuis le peripherique source 69 ont ete initialises par le pont 67 dans le paquet 
240. 

Pour cela, le pont utilise la valeur stockee dans le champ "offset" 
232 du paquet 231 qu'il aura prealablement communique au p6riph§rique 

15 source 69, par exemple, par I'intermediaire d'un paquet asynchrone 
prec6demment recu. Ainsi, si, par exemple, le paquet 231 de la figure 7 
constitue la r6ponse du peripherique 69 au paquet recu 226 sur la figure 6, on 
notera que la valeur des champs 223 et 224 du paquet de donnees 226 est 
identique respectivement a la valeur des champs 232 et 233 du paquet 231 de 

20 la figure 7. 

On notera aussi que dans ce cas, la valeur des champs 209, 210, 
211 du paquet 216 de la figure 6 est respectivement egale a la valeur des 
champs 246, 247 et 248 du paquet 240 de la figure 7. De m§me, la valeur des 
champs 212, 213, 214 et 215 du paquet 216 est egale respectivement a la 
25 valeur des champs 241 , 242, 243 et 244 du paquet 240. 

Lors du transfert du paquet 231 a travers le pont 67, ce dernier a 
insure le premier champ d'informations qui est forme des champs 244, 243, 

242, 241 et 246. Ce premier champ d'informations identifie le chemin restant a 
parcourir au paquet de donnees 231 pour parvenir a destination. 

30 Le pont 67 a ensuite ajoute dans un deuxieme champ 

d'informations, vide au prealable, une deuxieme information constitute par les 
bits "011" du registre 78 d'identification d'un equipement d'interconnexion ou 
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"portal" considered Cette deuxieme information est representee par le champ 
248. 

Ce deuxieme champ d'informations identifie le chemin parcouru 
par le paquet 231 depuis le peripherique 69 et ce sera le chemin d'informations 
5 dit de "retour" qui lui permettra, eventuellement, d'etre renvoy6 au peripherique 
source. 

Le troisieme champ d'informations correspond a une partie du 
champ 236 qui est transformee dans le paquet 240 en un champ 247 appel6 
"marqueur". 

10 Le precede de transfert de paquets precede egalement, apres la 

suppression de la premiere information et avant I'ajout de la deuxieme 
information, a la lecture de la table de routage associee a I'equipement 
d'interconnexion du registre 79. 

Le contenu du champ 235, code sur 6 bits, est representatif de 

15 I'identificateur physique du peripherique 69 parmi tous les peripheriques du bus 
59. Le champ 235 du paquet 231 a ete remplace par le champ 249 dans le 
paquet 240. La valeur du champ 249 , est quant a elle representative de 
I'identificateur virtuel du peripherique 69 parmi tous les peripheriques du bus 
59. 

20 Le champ 234, code sur 6 bits, est repr6sentatif de I'identificateur 

virtuel du peripherique destinataire 68 du paquet asynchrone parmi tous les 

peripheriques du bus 52. 

On notera que la valeur du champ 234 est egale a la valeur du 

champ 204 des figures 5 et 6. De m§me, la valeur du champ 249 est egale a la 
25 valeur du champ 203 des figures 5 et 6 et la valeur du champ 235 est §gale a la 

valeur du champ 221 de la figure 6. 

Ainsi, on comprend que, lors du transfert d'un paquet par un pont 

intermediaire, I'identificateur de routage de I'equipement d'interconnexion ou 

"portal" par lequel arrive le paquet est supprime du premier champ 
30 d'informations car il est devenu inutile et I'identificateur de routage de 

I'equipement d'interconnexion ou "portal" par lequel le paquet quitte le pont est 
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ajoute dans un deuxieme champ d'informations afin de reconstruire le chemin 
parcouru par le paquet. 

Les deux identificateurs ayant la meme longueur, la longueur 
totale des premier, deuxieme et troisieme champs d'informations (figure 5) reste 
5 inchang6e. 

En reduisant la longueur du premier champ et en augmentant la 
longueur du deuxieme champ au fur et a mesure du transfert du paquet par 
differents ponts du reseau on peut done augmenter la distance maximale 
parcourue par un paquet par rapport a Cart anterieur dans lequel la longueur de 
1 0 chaque champ destination et source reste fixe au cours du temps. 

II convient de remarquer que le troisieme champ ou marqueur a 
une longueur au moins egale au nombre de bits necessaire pour coder un 
identificateur de routage d'un equipement d'interconnexion ou "portal". 

Comme prec6demment mentionne, le marqueur comporte une 
15 suite predeterminee de bits qui peut etre, par exemple, une suite consecutive 
de bits ayant tous un m§me 6tat "0" ou"1". 

L'utilisation et la gestion du champ "offset" par les ponts source et 
destination sont plus particulierement decrites en reference aux figures 8, 9 et 
10. 

20 La figure 8 est une vue schematique detaillee d'une table de 

routage illustree par chaque registre 95, 96 de la figure 4 et qui est stockee 
dans la memoire RAM de chaque equipement d'interconnexion ou "portal" d'un 
pont source ou destination. Cette table a pour objectif d'associer a un index 
("offset" en terminologie anglo-saxonne) unique sur le bus local, un chemin 

25 permettant d'atteindre un peripherique distant et vice-versa. 

Cette table est composee d'un ensemble d'enregistrements 
elementaires 250 a 259, chaque enregistrement elementaire etant assocte a un 
index dans la table. Les enregistrements 250, 251, 252, 253, 254, 255, 256, 
257, 258 et 259 sont respectivement associes aux index "0", "1", "2", "3", "4", 

30 "5", "6", "7", "8", "9". 

La structure d'un enregistrement elementaire est par exemple 
constitute des champs suivants. 
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Le champ 270 "path_descriptor" correspond a un "descripteur de 
chemin", represente sur 16 bits et qui contient I'information de routage 
permettant d'atteindre le peripherique destinataire distant. 

Le champ 271 "activ" (raccourci de "activity", terminologie anglo- 
5 saxonne de "activite") represente sur 16 bits, contient I'information concernant 
la gestion au niveau du bus local dudit descripteur de chemin. 

Ce champ est notamment utilise pour connaTtre, a un moment 
donne\ combien de transactions de type "Requete" et "en attente de Reponse" 
sont en cours de traitement. 
10 Ce champ peut egalement etre utilise afin de connaTtre depuis 

combien de temps I'enregistrement elementaire n'a pas ete consulte. 

Pour ce faire, un compteur est increments suivant une peYiode 
predefinie par I'equipement d'interconnexion ou "portal" et est remis a z6ro a 
chaque utilisation de I'information "descripteur de chemin" ou de I'index. Ce 
1 5 champ permet ainsi d'optimiser la gestion de la memoire de la table de routage. 

II convient de noter que les index ("offsets") des enregistrements 
elementaires, non en cours d'utilisation et/ou n'ayant pas ete utilise depuis un 
certain temps, sont de preference reutilises en premier. 

Le champ 272 "local_bus_bit_map", represente sur 64 bits, 
20 permet de decrire quels sont les peripheriques sur le bus local qui utilisent 
effectivement ce descripteur de chemin. Chacun des 64 bits, indexes de 0 a 63, 
correspond au peripherique dont I'identificateur physique a pour valeur I'index 
en question. 

Comme pr6cedemment mentionne, ce champ permet d'optimiser 
25 la gestion de la memoire de la table, en evitant de r6utiliser un index qui est 
utilise, m§me peu souvent, par un nombre eleve de p6ripheriques. 

Ce champ pr6sente surtout I'avantage de pouvoir determiner, 
dans le cas ou un index a ete attribu6 a un autre enregistrement elementaire, si 
I'index est toujours d'actualite pour un peripherique donne sur le bus local. 
30 La figure 8 decrit par exemple une table de routage pouvant 

contenir jusqu'a dix enregistrements elementaires qui sont alors indexes de 0 a 
9. Chaque enregistrement elementaire contient trois mots de 32 bits. La taille 
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maximale des enregistrements elementaires etant atteinte, une gestion de 
ceux-ci est necessaire afin d'en liberer avant de pouvoir en ajouter. 

On notera que la longueur des champs 270, 271 et 272 est 
indicative et peut etre r6duite ou augmentee suivant les capacites du reseau. 
5 Ainsi, par exemple, si Ton autorise un maximum de 32 

peripheYiques par bus, ceci incluant les ponts, la longueur du champ 272 
"local_bus_bit_map" peut etre reduite a 32 bits et le nombre total d'index peut 
§tre augmente jusqu'a 15 pour une meme occupation de la memoire. 

Cette gestion peut obeir a differentes politiques comme par 
10 exempie celle selon laquelle les enregistrements elementaires non en cours 
d'utilisation et n'ayant pas ete utilise depuis une certaine duree sont liberes. 

De meme, le nombre de peripheriques qui ont utilise et qui sont 
encore susceptibles d'utiliser un enregistrement elementaire donn§ peut 
avantageusement etre pris en compte. 
15 La figure 9 est une vue schematique de I'algorithme d'un proc6d6 

de recuperation d'un descripteur de chemin a partir d'un index dans la table de 
routage decrite en figure 8. 

Ce precede est, par exemple, mis en ceuvre dans le pont 67 de la 
figure 7 lors du transfert du paquet 231 du bus 59 vers le bus 58. 
20 Ces instructions ou etapes d'un tel precede sont stockees dans la 

memoire ROM du pont considere. 

Au cours d'une etape 301, !e precede prevoit de recevoir une 
requete de recuperation d'un descripteur de chemin a partir d'un index donne. 

Au cours de I'etape 302, il est verifie que I'index en question se 
25 refere bien a un enregistrement elementaire dans la table de routage. Dans le 
cas positif, le traitement se poursuit par I'etape 303. Dans le cas negatif, le 
precede prevoit de retourner une information signifiant qu'aucun descripteur de 
chemin n'est valide pour ledit index (etape 305). 

Au cours de I'etape 303, le precede comporte une etape de 
30 verification selon laquelle I'enregistrement elementaire correspond bien a 
I'index presente par le peripherique a I'origine de la requete. II se peut en effet 
que I'enregistrement elementaire correspondant audit index ait ete supprim6 de 
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la table, puis que cette valeur d'index ait ete reutilisee pour decrire un autre 
enregistrement elementaire pour un autre peripherique. 

Pour ce faire, un ensemble de 64 bits (indexes de 0 a 63) est 
utilise pour dresser une carte des peripheriques utilisant I'enregistrement 
5 elementaire en question. 

Chaque bit permet de savoir si, pour le peripherique dont 
I'identificateur physique a pour valeur I'index parmi les 64 bits, I'enregistrement 
- Elementaire est valide ou non. 

Dans le cas ou I'information est dite non valide, le precede prevoit 
10 de retourner une information signifiant qu'aucun descripteur de chemin n'est 
valide pour ledit index (etape 305). 

Dans le cas ou I'information est valide, I'etape 303 est suivie de 

I'etape 304. 

Au cours de I'etape 304, le precede effectue une lecture du 
15 descripteur de chemin, met a jour les informations de gestion relatives a 
I'enregistrement elementaire, et retoume finalement le descripteur de chemin 
pour ledit index. 

Parmi les informations de gestion relatives a I'enregistrement 
elementaire, on peut notamment citer les deux actions suivantes : 
20 Premierement, quand une demande de recuperation d'un 

descripteur de chemin a partir d'un index est issue d'une transaction de type 
"Requite", un compteur indiquant I'usage de cet enregistrement elementaire 
est incr6mente si une transaction de type "Reponse" est attendue. Ce compteur 
sera decrements lors d'une prochaine demande de recuperation d'un index a 
25 partir d'un descripteur de chemin issue d'une transaction de type "R6ponse". 

Deuxiemement, a chaque utilisation de I'enregistrement 
elementaire, le compteur indiquant la duree ecoulee depuis la derniere 
utilisation de cet enregistrement est remis a zero. 

Ce dernier compteur peut par exemple etre increments sur un 
30 evenement temporel genere avec une periode predefinie. 

Apres avoir retourne le descripteur de chemin ou I'absence de 
descripteur de chemin pour ledit index, le precede prevoit de revenir a I'etape 
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301 pour traiter toute nouvelle demande de recuperation d'un descripteur de 
chemin a partir d'un index dans la table de routage. 

La figure 10 est une vue schematique de ralgorithme d'un precede 
de recuperation d'un index a partir d'un descripteur de chemin dans la table de 
5 routage decrite en figure 8. 

Ce procede est par exemple mis en ceuvre dans le pont 67 de la 
figure 6 lors du transfert du paquet 216 du bus 58 vers le bus 59. 

Les instructions ou etapes d'un tel procede sont stockees dans la 
memoire ROM du pont considere. 
10 Au cours d'une etape 311, le procede prevoit de recevoir une 

requete de recuperation d'un index a partir d'un descripteur de chemin donne. 

Au cours de I'etape suivante 312, le procede prevoit de verifier 
que le descripteur de chemin en question est present dans la table de routage. 

Dans le cas positif, I'etape 312 est suivie de I'etape 315, au cours 
15 de laquelle on met a jour, le cas echeant, les informations de gestion relatives a 
I'enregistrement elementaire, et I'index correspondant audit descripteur de 
chemin est retourne. 

Concernant les informations de gestion relatives a 
I'enregistrement elementaire, on peut notamment citer les deux actions 
20 suivantes : 

Premierement, quand une demande de recuperation d'un 
descripteur de chemin a partir d'un index est issue d'une transaction de type 
"Reponse", le compteur indiquant I'usage de cet enregistrement elementaire est 
decremente. 

25 Deuxiemement, le compteur indiquant la duree ecoulee depuis la 

demiere utilisation de cet enregistrement est remis a zero. 

Ce dernier compteur peut par exemple etre increments sur un 
evenement temporel genere avec une periode predefinie. 

Dans le cas negatif, le procede comporte une etape 313 au cours 
30 de laquelle il est verifie si au moins un index (et done un enregistrement 
elementaire) est libre dans la table de routage. 
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Dans le cas positif, au cours d'une etape 314, un index est affects 
et utilise pour stocker le descripteur de chemin d'informations. 

Un bit parmi I'ensemble des 64 bits (indexes de 0 a 63) qui 
correspond a I'identificateur physique du p6ripherique a I'origine de la 
5 demande, est positionne afin de valider cet enregistrement elementaire pour le 
peripherique en question. 

Si I'index n'est pas libre, le precede precede a la liberation d'un ou 
plusieurs index (et done d'enregistrement(s) elementaire(s)) dans la table de 
routage au cours d'une etape 316. 
10 L'etape suivante 317 consiste a verifier si l'etape de liberation a pu 

se faire avec succes. Dans le cas positif, l'etape 314 prec6demment decrite est 
a nouveau effective. Dans ie cas negatif, au cours d'une etape 318, le precede 
prevoit de retourner une information indiquant ('absence d'index (et done 
d'enregistrement elementaire) pour ledit descripteur de chemin. Ensuite, l'etape 
15 31 1 est executee de nouveau. 

La figure 11 repr6sente un algorithme sur lequel est base un 
precede de routage des paquets asynchrones au niveau d'un pont. 

Les instructions ou etapes d'un tel precede sont stock6es dans la 
memoire ROM de chaque pont. 
20 Cet algorithme concerne la prise de decision de routage desdits 

paquets ainsi que la transformation de leurs en-tetes, en fonction du r6sultat de 
I'analyse du contenu des en-tetes des paquets regus. 

Dans la suite de la description, des variables temporaires 
stockees dans la memoire RAM du pont considere (D_BuslD, S_BuslD, in_RI, 
25 out_RI, path_register) ont ete introduites pour faciliter la comprehension de 
I'algorithme sur lequel est base le precede. 

Le precede debute par une etape notee 100 sur la figure 11 
consistant en I'attente de la reception d'un paquet asynchrone. Lorsqu'un tel 
paquet a ete recu et stocke en memoire, on passe a l'etape 401 d'analyse de 
30 I'identificateur du bus de destination D_BuslD compris dans I'en-tete dudit 
paquet. 
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Dans la suite de la description, D_BuslD represents I'information 
du champ "destinationJBusJD" de la figure 2, de m§me S_BuslD represents 
rinformation du champ "source_Bus_ID" de cette m§me figure. 

Si ledit identificateur est egal a 3FFi6, il s'agit alors soit d'un 
5 paquet 6mis sur le bus local et destin6 a ce bus local, soit d'un paquet distant 
arrive sur son bus de destination (comme decrit en figure 6). Dans ce cas 
d'egalite, I'etape 401 est suivie par I'etape 402 consistant, puisque ce paquet 
est destine audit bus local, a rejeter le paquet sans autre traitement. L'6tape 
402 est suivie par I'etape 400 d'attente d'un nouveau paquet asynchrone. 
10 Lorsqu'au cours de I'etape 401 on trouve un identificateur du bus 

de destination different de 3FFi 6 , cela signifie que le paquet est au niveau d'un 
pont intermediate et les etapes 403 et 404 sont alors executees. 

II convient de noter que, dans la suite de la description, selon le 
cas de figure envisage, I'information ou identificateur (ou label) de routage du 
15 descripteur de chemin de destination est lu dans les bits de poids faibles du 
champ D_BuslD et I'information ou identificateur (ou label) de routage du 
descripteur de chemin parcouru est ecrit dans les bits de poids faibles du 
champ S_BuslD, les bits 6tant decales d'un champ a I'autre de facon 
appropriee. 

20 Par exemple, on procede a un decalage a droite du champ 

D_BuslD et a un decalage a gauche du champ S_BuslD, chaque bit issu du 
decalage a gauche du bit de poids fort du champ S_BuslD etant insere, apres 
decalage a droite des bits du champ D_BusID , a la place du bit de poids fort du 
champ D_BuslD. 

25 D'autres variantes consistant a combiner lecture/ecriture des 

informations de routage des descripteurs de chemin sur les poids forts/faibles 
des champs D_BuslD et S_BuslD avec les decalages appropries ne sont pas 
decrites dans la presents description, mais peuvent etre envisag6es par 
I'homme du metier. 

30 De retour a Palgorithme de la figure 11, I'etape 403 consiste a 

determiner I'identificateur ou label de routage du descripteur de chemin de 
destination in_RI. 
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Pour ce faire I'identificateur ou label de routage est extrait du 
champ D_BuslD d'une longueur ou taille (en bits) egale au contenu du registre 
"routing_width_30" 92 (figure 4) associe a I'equipement d'interconnexion ou 
"portal" d'entree ("inbound portal" en terminologie anglo-saxonne). 
5 Dans I'exemple de la figure 5 , le champ D_BuslD vaut 

"1111 011 001 2 ", la valeur routing_width_30 est egale a 3 et I'identificateur ou 
label de routage in_RI est egal a 00 1 2 . 

Une fois la valeur de I'identificateur ou label de routage in_RI du 
paquet connue, I'etape 404 permet de la comparer au contenu du registre 
10 "routing_label_30" 91 qui constitue I'unique identificateur ou label de routage 
affecte pour le bus considere a i'equipement d'interconnexion ou "portal" sur 
lequel le paquet en question a ete recu. 

Si les deux valeurs sont differentes, alors I'etape 405 est 
executee. Cette etape consiste a rejeter le paquet puis a passer a I'etape 400 
15 decrite ci-dessus. 

Dans le cas contraire, c'est-a-dire lorsque les valeurs in_RI et 
routing_label_30 sont egales, I'etape 404 est suivie du test 406 afin d'analyser 
I'identificateur du bus source S_BuslD compris dans l'en-tete du paquet traits. 

Si I'identificateur est egal a 3FFi 6 cela signifie que le paquet est 
20 situe au niveau d'un pont source, alors le paquet est dit "distant" (destinataire 
sur un bus distant) et est recu de son bus source (comme par exemple le 
paquet reference 231 en figure 7). L'en-tete de ce paquet sera alors traite 
suivant les etapes 410, 411, 412, 413 ou 414 et 415 decrites de facon plus en 
detail ci-dessous. 

25 Dans le cas contraire, le paquet "distant" traite transite sur un bus 

interm6diaire entre son bus source et son bus de destination (comme par 
exemple le paquet reference 216 en figure 5). Le traitement de l'en-tete du 
paquet suit alors les etapes 420 et 421 egalement decrites ci-dessous. 

Pendant I'etape 410, on extrait du champ DJ3uslD du paquet un 

30 index ("offset" en terminologie anglo-saxonne) de routage (pr6cedemment 
defini lors de la description des figures 6 et 7) en tenant compte de la valeur 
routing_width_30 mentionnee ci-dessus lors de I'explication de I'etape 403. Cet 
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index ("offset") est constitue des (10 - routing_width_30) bits de poids forts du 
champ D_BuslD, 10 etant la largeur dudit champ D_BuslD. 

Par exemple, dans le cas ou le champ D_BuslD vaut 
"0001101 OOO2" et la valeur routing_width_30 est egale a 3, I'index sera egal a 
5 00011012. 

Ensuite, pendant I'etape 411, I'index ("offset") est converti en 
descripteur de chemin selon le procede de recuperation d'un descripteur de 
chemin a partir d'un index dans la table de routage, tel que decrit ci-dessus 
(figure 9, etapes 301 a 305). 
10 Un test 412 consiste alors a verifier si un tel descripteur de chemin 

a 6te trouv6 au cours de l'ex6cution du procede. 

Dans le cas negatif, on execute I'etape 413 consistant a rejeter le 

paquet traite. 

Dans des variantes de mise en oeuvre de ce procede\ des 
15 methodes de traitement d'erreur plus sophistiquees (dont le detail n'est pas 
reproduit sur les figures) peuvent etre envisagees au cours de I'etape 413. 

De telles methodes consistent, par exemple, a envoyer un 
acquittement n6gatif au peripherique dont est issu le paquet pour lequel le 
descripteur de chemin est obsolete, permettant a celui-ci d'ajuster sa table de 
20 routage sans attendre I'expiration d'une certaine duree ("time-out" en 
terminologie anglo-saxonne). 

L'etape 413 est suivie par I'etape 400 d'attente d'un nouveau 
paquet a traiter deja decrite ci-dessus. 

Dans le cas positif du test 412, le descripteur du chemin, retourn6 
25 par I'etape 411, est stocke dan's le registre "pathregister" au cours de I'etape 
414. Le registre "path_register" est utilise pour la gestion des descripteurs de 
chemin (chemin destination et chemin parcouru) et est avantageusement 
compose de deux sous-champs, chacun de ces sous-champs correspondant 
aux informations respectivement contenues dans les champs D_BuslD et 
30 S_BuslD. 

Ensuite, au cours de I'etape 415, le procede effectue, sur le 
registre "path_register", le remplacement de I'identificateur physique du 
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p6riph£rique present dans le champ de I'adresse source 235 du paquet de la 
figure 7 par I'identificateur virtuel correspondant, ceci en utilisant une table de 
correspondance appropriee etablie lors de chaque reinitialisation ("bus reset" 
en terminologie anglo-saxonne) du bus source 52 de la figure 1. Cette table 
5 etablissant la correspondance entre identificateurs physiques et virtuels des 
differents equipements (peripheriques, ponts, ...) connectes a un bus est bien 
connue de I'homme du metier et est d'ailleurs illustree a la figure 21 . 

L'etape 415 est alors suivie par une etape 430 dont la description 
est faite plus loin. 

10 De retour a l'etape 406, si I'identificateur est different de 3FFi 6 , 

alors cette etape est suivie d'une 6tape 420 de traitement d'un paquet recu a 

partir d'un bus intermediate. 

L'etape 420 consiste a charger (memorisation) le registre 

"path_register" a partir des identificateurs de bus D_BuslD et S_BuslD extraits 
15 respectivement des champs "sourceJD" 81 et "destinationJD" 80 de I'en-tete 

(figure 2) du paquet traite. 

On rappelle ici que chacun des deux identificateurs du bus est 

constitu6 des 10 bits de poids fort du champ d'adresse correspondant (80 ou 

81), tandis que les 6 bits restants desdits champs d'adresse represented 
20 I'identificateur (soit physique, soit virtuel) du p6riph6rique adress6 sur le bus 

donne. 

L'operation de chargement tient compte du mode de gestion des 
champs D_BuslD et S_BuslD mentionn6 pr6cedemment comme, par exemple, 
le decalage a droite du champ D_BuslD et le decalage a gauche du champ 
25 S_BuslD, et ou chaque bit issu du decalage a gauche du bit de poids fort du 
champ S_BuslD est insert, apres decalage a droite des bits du champ 
D_BuslD, a la place du bit de poids fort du champ D_BuslD. 

Ensuite, au cours de l'etape 421, le contenu du registre 
"path_register" est transforms de la facon indiquee ci-apres (pour une meilleure 
30 comprehension de cette etape, le lecteur est prie de se referer a la figure 5). 

On repere tout d'abord une sequence de longueur maximale 
comportant au moins (2 max_width - 1) bits consecutifs a "1" (max_width etant 
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la valeur du registre 97 de la figure 4) constituant un marqueur ou separateur 
entre le champ identifiant le chemin de destination et le champ identifiant le 
chemin parcouru. Dans I'exemple du paquet 199 illustre a la figure 5, la 
sequence comporte 5 bits a "1", la sequence "011 001 2 " decrit le chemin de 
5 destination, et la sequence "011 01 0 01 1 2 " decrit le chemin parcouru.. 

II convient de noter ici qu'en separant les trois champs cites de la 
maniere precedemment decrite, on peut attribuer (de fagon erronee) au 
marqueur d'eventuels bits adjacents appartenant au champ du chemin parcouru 
et/ou au champ du chemin de destination dans le cas ou lesdits bits sont egaux 

10 a "1". Ceci ne constitue toutefois pas un probleme pour le fonctionnement 
correct de I'algorithme d6crit. 

On effectue ensuite un decalage dans le registre "path_register", 
selon le mode de gestion adopte, des bits du champ descripteur du chemin de 
destination (identificateur du chemin a parcourir) d'un nombre de bits qui est 

15 egal a la valeur routing_width_30. 

Les bits non significatifs, suite au decalage, se trouvent 
positionnes a "1" et les bits du marqueur ne sont pas modifies. Le registre 
"routing_width_30" 92 indique la longueur en bits de I'identificateur ou label de 
routage sur le bus d'entree du paquet traite. 

20 Ainsi, dans I'exemple de la figure 5, les bits du champ 202 ont 

disparu, les bits du champ 201 ont ete decale d'un nombre de bits egal a la 
valeur routing_width_30 (a droite dans le champ "destination_Bus_ID" 80a de la 
figure 2) et occupent maintenant le champ reference 211, les bits devenus non 
significatifs du champ reference 201 sont mis a "1", les bits du marqueur, 

25 reference par les champs 200 et 205 restant inchanges. 

II convient de noter que la taille ou longueur en bits du marqueur 
se trouve ainsi augmentee d'un nombre egal a la valeur routing_width_30. 

On effectue alors un decalage dans le registre "path_register", 
selon le mode de gestion adopte, des bits du marqueur du chemin parcouru 

30 (identificateur du chemin parcouru) d'un nombre de bits qui est egal a la valeur 
routing_width_32, un nombre de bits egal a la valeur routing_width_32 des bits 
du marqueur se trouvant alors ecrit. 
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Rappelons ici que le registre "routing_width_32" 94 associS a 
l'6quipement d'interconnexion ou "portal" de sortie ("outbound portal" en 
terminologie anglo-saxonne) indique en fait la longueur en bits de I'identificateur 
ou label de routage sur le bus de sortie du paquet traite. 
5 La valeur des bits decrivant I'identificateur ou label de routage 

pour le descripteur du chemin parcouru (identificateur du chemin parcouru) sera 
determinee pendant I'etape 450 executee ulterieurement. 

Dans I'exemple de la figure 5, les bits d'informations des champs 
206, 207 et 208, decrivant le chemin parcouru, ont ete decale d'un nombre de 
10 bits egal a la valeur routing_width_32 (a gauche dans le champ 
"source_Bus_ID" 81a de la figure 2 puis a droite dans le champ 
"destination_Bus_ID" 80a de la figure 2) et occupent alors respectivement les 
champs 209 et 212 pour le premier, 213 pour le second et 214 pour le 
troisieme. Les champs 209 et 212 faisant auparavant partie du marqueur 
15 contiennent desormais des informations decrivant le chemin parcouru. Le 
champ 215 va etre affecte lors de I'operation decrite a I'etape 450. 

Lors des differentes phases mentionnees ci-dessus et qui ont lieu 
au cours de I'etape 421, le marqueur s'est egalement trouve deplace par 
rapport a sa position anterieure a I'interieur du registre "path_register". 
20 Si la valeur routing_width_32 est superieure a la valeur 

routing_width_30, alors la longueur du marqueur est reduite de la difference. 

De facon similaire, si la valeur routing_width_32 est inferieure a la 
valeur routing_width_30, alors la longueur du marqueur est augment6e de la 
difference. 

25 II convient de noter qu'en suivant cette regie, la longueur du 

marqueur reste superieure ou egale a la valeur 4*max_width - 1 - 
routing_width_30 - routing_width_32 (qui est toujours superieure ou egale a 
2*max_width - 1) dans chaque pont traverse a condition que cette condition soit 
remplie initialement. 

30 Ceci garantit que le marqueur reste identifiable par chaque pont. 

Dans I'exemple de la figure 5, le marqueur ou champ s6parateur auparavant 
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constitue des champs 200 et 205, se trouve, apres passage du pont 66, 
represents par le champ 210, sa longueur etant restee de 5 bits. 

Dans la presente description, la taille ou longueur des 
identificateurs ou labels de routage est fixe dans tout le reseau bien que cela ne 
5 soit pas imperatif. Ceci implique que les registres "routing_width_30" 92, 
"routing_width_32" 94 et "max_width" 97 comportent la meme valeur dans 
chaque pont du reseau. On notera que, pour ce faire, il suffit que le marqueur 
comporte au moins un nombre de bits egal a la valeur "max_width" (au lieu de 
2*max_width - 1 bits dans I'hypothese d'une longueur variable des 
10 identificateurs ou labels de routage). 

Dans une variante de realisation, les registres "routing_width_30" 
92, "routing_width_32" 94 peuvent comporter des valeurs differentes pour un 
meme pont du reseau. 

On notera que la description faite en reference a la figure 1 et qui 
1 5 precede s'applique a cette variante. 

L'etape 421 est suivie par les etapes 430 de lecture du champ 
compose des (routing_width_32) bits du premier champ (equivalent de 
D_BuslD) du registre "path_register" et par le test 431 afin de determiner si tous 
les bits lus sont egaux a "1", c'est-a-dire si le paquet est arrive sur son bus de 
20 destination. Dans 1'affirmative, les etapes 440, 441, 442 et 443 sont executees, 
sinon on passe aux etapes 450 et 451 . 

Pour une meilleure comprehension de la description des etapes 
440 a 443 du traitement d'un paquet arrivant sur son bus de destination 59, le 
lecteur est prie de se referer a la figure 6. 
25 Lors de l'etape 440, le champ 203 de fen-tete du paquet 

asynchrone constituant I'identificateur virtuel du peripherique ou equipement 69 
destinataire dudit paquet sur le bus 59 est remplace par I'identificateur physique 
221 qui lui correspond en utilisant la table de correspondance appropriee. 

L'etape 441 consiste a convertir I'identificateur du chemin 
30 parcouru contenu dans le registre "path_register" en index 223 ("offset") comme 
decrit ci-dessus en reference aux etapes 31 1 a 318 de la figure 10. 
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Au cours de I'etape 442, le champ de I'en-tete identifiant le chemin 
parcouru est initialise avec la concatenation dudit index 223 ("offset") et du 
contenu 224 du registre "routingJabel_32" 93 (figure 4) en tenant compte du 
nombre des bits valides de I'identificateur ou label de routage, indique par le 
5 registre "routing_width_32" 94. 

Ensuite, au cours de I'etape 443, le champ de I'en-tete 220 
identifiant le bus de destination est initialise avec la valeur 3FFi 6 . Ce traitement 
est suivi par I'etape 460. 

Au cours de I'etape 450 (lorsque les bits lus ne sont pas tous 
10 6gaux a "1"), les bits identifiant le chemin parcouru du registre "path_register" 
(nombre indique par la valeur routing_width_32) sont initialises avec 
I'identificateur ou label de routage 93 stocke dans le registre "routingJabeL^" 
associe a I'equipement d'interconnexion ou "portal" situe sur le bus de sortie du 
paquet traite. 

15 Pendant I'etape 451 les champs identifiant le bus source, c'est-a- 

dire les champs 212, 213, 214, 215, 209 et le bus de destination, c'est-a-dire 
les champs 210 et 211 sont respectivement initialises avec le contenu du 
registre "path_register". Ce traitement est egalement suivi par I'etape 460. 

L'etape 460 consiste a transferer le paquet sur le bus 58 (figure 7), 

20 respectivement 59 (figure 6). Cette etape est suivie par I'etape 400 d'attente 
d'un nouveau paquet a traiter. 

La figure 12 est une vue schematique d'un r6seau de bus lors de 
la diffusion d'un paquet de resolution d'adresse d'une part, et de son paquet 
reponse correspondant d'autre part. 

25 Ce reseau est compose des bus 501 a 505 interconnectes par les 

ponts 506 a 511. 

Le paquet de resolution d'adresse est envoye par un equipement 
source 513 afin d'obtenir un descripteur de chemin permettant ensuite 
d'acceder a I'equipement distant au moyen de paquets asynchrones tels que 

30 decrits dans le standard 1394-95. Ce paquet de resolution d'adresse est diffuse 
dans tout le reseau de bus ("broadcast" en terminologie anglo-saxonne). 
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Un mecanisme complementaire peut etre mis en oeuvre au niveau 
de chaque equipement d'interconnexion ou "portal" d'un pont pour eviter que le 
paquet ne soit transmis plus d'une fois sur le meme bus et ainsi eviter tout 
bouclage inflni dans le reseau de bus. Ce mecanisme, connu de l'homme du 
5 metier et decrit par exemple dans le livre "DATA NETWORKS, second edition, 
by Bertsekas Gallager, Prentice Hall International Editions, ISBN 0-13-201674- 
5" dans le chapitre intitule "Flooding and broacasting", s'appuie par exemple sur 
les principes suivants : le paquet en cours de diffusion est identifie de facon 
unique (par exemple a I'aide d'un numero d'identification unique qui est le 

10 numero EUI-64 de I'equipement source et d'un numero de sequence identifiant 
ce paquet de maniere unique dans ce meme equipement source), quand un 
equipement d'interconnexion ou" "portal" diffuse ce paquet, il memorise 
certaines d'informations qui lui permettront ensuite de savoir si un paquet de 
diffusion qu'il a regu doit ou ne doit pas etre diffuse sur I'autre equipement 

1 5 d'interconnexion ou "portal" du pont considere, le cas echeant sur chacun des 
autres equipements d'interconnexion ou "portals" dudit pont, notamment en 
fonction d'une precedents reception de ce m§me paquet. 

Les equipements d'interconnexion ou "portals" doivent, entre 
autre, a cette fin gerer une table de verification dite de "diffusion" comme par 

20 exemple celle decrite a la figure 15. 

Dans le cas ou ce paquet doit etre diffuse sur un bus, 
I'equipement d'interconnexion ou "portal" en question met a jour le descripteur 
de chemin qui permettra de dinger (router) directement le paquet r6ponse vers 
I'equipement qui est a I'origine du paquet de resolution d'adresse. La diffusion 

25 de ce paquet de resolution d'adresse est indiquee sur la figure 12 par les 
fleches 520, 521,522 et 523. 

Lorsque chaque equipement d'interconnexion ou "portal" d'un 
meme pont est regroupe dans un seul et m§me dispositif tel que celui 
represents a la figure 3, une seule table de verification dite de "diffusion" 

30 commune peut etre utilisee pour tous les equipements d'interconnexion ou 
"portals" d'un pont donne. 
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Sur un bus donne, chaque equipement d'interconnexion ou 
"portal", possedant en interne une table des numeros EUI-64 des differents 
equipements connectes sur le bus, est en charge de verifier, a la reception d'un 
paquet de resolution d'adresse, si I'equipement recherche est present ou non 
5 sur le bus. 

Dans le cas positif, I'equipement d'interconnexion ou "portal" du 
pont 506 par exemple celui connecte au bus 501 stoppe la diffusion du paquet 
de resolution d'adresse et emet un paquet de donnees asynchrone de reponse 
530 vers le pont 508 qui transfere cette reponse sous la forme d'un paquet 531 
10 au pont 510, a destination de I'equipement qui est a I'origine du paquet de 
resolution d'adresse. 

Pour ce faire I'equipement d'interconnexion ou "portal" recupere 
dans le paquet de resolution d'adresse le descripteur de chemin mis a jour lors 
de la diffusion. 

15 Le paquet de donnees asynchrone de reponse faisant route vers 

I'equipement 513 a I'origine du paquet de resolution d'adresse va construire le 
descripteur de chemin recherche. II en est de m6me pour I'equipement 
d'interconnexion ou "portal" du pont 507 qui va emettre un paquet de donnees 
asynchrone de reponse 533 vers le pont 510 (figure 12). 

20 II appartient a chaque equipement d'interconnexion ou "portal" des 

ponts du bus 504 , ou se situe I'equipement 513 a I'origine du paquet de 
resolution d'adresse, de reconnaftre les differents paquets de donnees 
asynchrones de reponse, de les filtrer et de n'en envoyer qu'un seul, reference 
534 sur la figure 12, vers I'equipement 513, dans le cas ou celui-ci ne viendrait 

25 pas deja d'un autre equipement d'interconnexion ou "portal" relie au bus 504. 

Pour ce faire, I'equipement d'interconnexion ou "portal" doit 
memoriser le fait que la requete de resolution d'adresse a ete suivie d'une 
reponse, par exemple en sauvegardant a partir de la premiere reponse regue, 
et ce pendant une certaine duree, des donnees comme le numero EUI-64 de 

30 I'equipement recherche et le numero de sequence identifiant le paquet de 
resolution d'adresse de maniere unique dans cet equipement source, et en les 
comparant avec celles effectivement regues dans les autres paquets reponses. 
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Les 6ventuels paquets de donnees asynchrones de reponse s'averant etre des 
doublons sont simplement ignores. 

La figure 13 est une vue schematique repr6sentant la structure 
d'un paquet de donnees de resolution d'adresse 550. Ce format de paquet est 
5 preferentiellement base sur le format d'un paquet global de flux asynchrone (en 
terminologie anglo-saxonne "Global Asynchronous Stream Packet" ou en 
abrege "GASP"). 

Les' champs 551 a 556 denommes "datajength", "tag", channel", 
"Ai6", "sy" et "header_CRC" ont des valeurs constantes definies par le comit6 
10 de normalisation 1394. 

La valeur du champ 557 "sourceJD" permet de specifier I'adresse 
de I'equipement d'interconnexion ou "portal" 6metteur du paquet. 

Les champs 558 a 560 denommes "specifiierJDJii", 
"specifiier_ID_lo", et "version" ont des valeurs constantes definies par le comity 
15 de normalisation 1394. 

Les champs 561 a 568 constituent une partie denommee "champ 
de donnees" ("data field" en terminologie anglo-saxonne) d'un paquet GASP et 
sont utilises de la facon indiquee ci-apres. 

Le champ descripteur de chemin 561 ("path_descriptor" en 
20 terminologie anglo-saxonne), repr6sente sur 20 bits, contient ('information de 
routage elaboree lors du cheminement du paquet de resolution d'adresse vers 
I'equipement destination recherche. La valeur de ce champ est done 
representative du chemin parcouru. La taille utile de ce champ est deiinie a 
partir de la valeur des champs "max_width" 97, "routing_width_30" 92, et 
25 "routing_width_32" 94 (figure 4) et des traitements effectues sur le chemin 
parcouru tels qu'explicites lors de la description de I'etape 421 de la figure 11. 
Par exemple, lorsqu'un paquet de resolution d'adresse present sur le bus 56 de 
la figure 1 est susceptible d'etre transfere par le pont 66 sur le bus 58 et que le 
champ 561 comporte, par exemple, les champs 200 et 205 a 208 de la figure 5, 
30 alors le contenu du champ 561 sera remplace par les champs 210, 209 et 212 a 
215 lors du transfert via le pont 66. 
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Le champ denomme "sequencejiumber" ("numero de sequence") 
et note 562, repr6sent6 sur 12 bits, permet d'identifier ce paquet de maniere 
unique dans I'equipement source a I'origine de la requete de resolution 
d'adresse. 

5 Les champs denommes "Src_EUI_64_hi" et "Src_EUI_64_lo" 

("EUI-64 source haut et bas") et notes respectivement 563 et 564, represented 
chacun sur 32 bits, decrivent le numero EUI-64 de I'equipement a I'origine de 
ce paquet de resolution d'adresse. Ce numero EUI-64 est utile pour identifier de 
maniere unique I'equipement source a I'origine de la requete de resolution 
10 d'adresse. 

Les champs denommes "Dev_EUI_64_hi" et "Dev_EUI_64_lo" 
{"EUI-64 equipement recherche haut et bas") et notes respectivement 565 et 
566, representes chacun sur 32 bits, decrivent le num6ro EUI-64 de 
I'equipement recherche par I'equipement a I'origine de ce paquet de resolution 
15 d'adresse. Ce num6ro EUI-64 identifie de maniere unique I'equipement 
recherche. 

Quand un equipement souhaite communiquer avec un 
equipement distant, celui-ci positionne, entre autres, les champs 563 et 564 
("Src_EUI_64_hi" et "Src_EUI_64_lo") avec son numero EUI-64, et le champ 

20 numero de sequence 562 avec une valeur unique pour cet equipement (valeur 
incr6mentee, par exemple, apres chaque emission d'un tel paquet). 

En sauvegardant, pendant une duree pr6determin6e par exemple 
6gale a une seconde, ce numero de sequence pour chaque equipement 
emetteur d'un paquet de resolution d'adresse, chaque equipement 

25 d'interconnexion ou "portal" du reseau peut ainsi eviter d'emettre a nouveau ce 
paquet sur le(s) bus adjacent(s). 

Le champ denomme "response packet type specific information" 
("information specifique pour le paquet reponse") et note 567, repr6sente sur 48 
bits, contient ('information necessaire pour construire le paquet reponse en 

30 reponse au paquet de resolution d'adresse. Cette information est positionn6e 
par I'equipement emetteur du paquet de resolution d'adresse. Ce champ 
sp6cifie notamment, dans le cas ou le paquet reponse est base, par exemple, 
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sur un paquet primaire asynchrone ("asynchronous primary packet" en 
terminologie anglo-saxonne) de type ecriture (decrit dans la norme 1394-95), 
I'adresse de destination dans I'equipement source qui est a I'origine du paquet 
de resolution d'adresse, adresse a laquelle I'equipement destinataire recherch6 
5 pourra ecrire des donnees en reponse a la requeue. Le paquet de reponse est 
par exemple un paquet de type requete d'ecriture d'un bloc de donnees ("write 
request for data block" en terminologie anglo-saxonne). 

Un champ denomme "reserved" ("reserve") et note 568, 
represents sur 16 bits, comme son nom I'indique, n'est pas utilise pour I'instant. 
10 La valeur d'un champ denomme "data_CRC" et note 569 est 

calculee en fonction de la valeur des champs 557 a 568 selon des regies 
predeterminees par le comite de normalisation 1394. 

La figure 14 est une vue sch6matique representant la structure 
d'un paquet de donnees asynchrone 580 de reponse au paquet de resolution 
15 d'adresse 550 decrit precedemment. Le format d'un tel paquet est largement 
decrit dans le standard 1394-95 et est illustre en figure 2. Seuls les champs 
utiles dans le cadre du present document sont decrits ci-apres. 

Comme il a ete mentionn6 precedemment, la valeur d'un champ 
denomme "tCode" et note 585 peut par exemple correspondre a une requete du 
20 type "write request for data block". 

Un champ denomme "reserved" ("reserve") et note 590, 
represents sur 16 bits, comme son nom I'indique, n'est pas utilise pour I'instant. 

Un champ denomme "sequence_number" ("numero de 
sequence") et note 591, represente sur 12 bits, permet d'identifier le paquet de 
25 maniere unique dans I'equipement qui est a I'origine de la requete de resolution 
d'adresse. 

Des champs denommes "Src_EUI_64_hi" et "Src_EUI_64_lo" 
("EUI-64 source haut et bas") et notes respectivement 592 et 593, representes 
chacun sur 32 bits, decrivent le numero EUI-64 de I'equipement a I'origine du 
30 paquet de resolution d'adresse. Ce numero EUI-64 est utile pour identifier de 
maniere unique I'equipement qui est a I'origine de la requete de resolution 
d'adresse. 
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Les champs 592, 593 ("Src_EUI_64_hi" et "Src_EUI_64_lo") et le 
champ 591 ("sequence_number") permettent notamment a chaque equipement 
d'interconnexion ou "portal" sur le bus dit "source" (bus od se situe I'equipement 
qui est a I'origine de la requete de resolution d'adresse) de savoir si une 
reponse a deja ete envoyee a I'equipement qui est a I'origine de la requite de 
resolution d'adresse. 

Les equipements d'interconnexion ou "portals" sur le bus "source" 
doivent pour cela gerer une table de verification dite de "reponse" comme par 
exemple celle decrite en figure 15. 

On notera que la detection et le traitement du bouclage ("loop 
detection" en terminologie anglo-saxonne) concerne une amelioration apportee 
au precede de routage d'un paquet de resolution d'adresse et qui utilise des 
precedes decrits dans I'etat de Tart. 

En effet, un traitement par defaut du bouclage est mis en ceuvre 
par le precede de routage d'un paquet de resolution d'adresse lors du 
traitement associe au champ 561 : lorsque la totalite de la zone utile du champ 
561 du paquet de resolution d'adresse est utilisee pour decrire le chemin 
parcouru, le precede de transfert du paquet d'un bus a I'autre est stoppe. 

Ainsi, le precede de transfert de paquet va consommer, par 
insertion d'identificateurs ou labels de routage lors de chaque boucle, une partie 
de la zone utile du champ 561 du paquet de resolution d'adresse, jusqu'a 
remplir la totalite du champ, ce qui a pour effet de mettre fin au transfert du 
paquet. 

La figure 15 est une vue schematique detaillee representant une 
table de verification 600 stockee dans la memoire RAM de la figure 3. Ce type 
de table peut etre utilise par les deux types de verification precedemment 
decrits : 

- diffusion d'un paquet de resolution d'adresse d'une part, 

- generation d'un seul et unique paquet de reponse correspondant 
a un paquet de resolution d'adresse sur le bus ou se situe I'equipement qui est 
a I'origine de ce paquet de resolution d'adresse. 
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La figure 15 illustre par exemple une table de verification 
contenant un nombre limite d'enregistrements elementaires notes 601 a 605. 

Des champs denommes "Src_EUI_64_hi" et "Src_EUI_64_lo" 
("EUI-64 source haut et bas") et notes respectivement 610 et 611, represents 
5 chacun sur 32 bits, decrivent le numero EUI-64 de I'equipement qui est a 
I'origine du paquet de resolution d'adresse. Ce numero EUI-64 est utile pour 
identifier de maniere unique I'equipement qui est a I'origine du paquet de 
resolution d'adresse. 

Un champ denomme "sequence_number" ("numero de 
10 sequence") et note 612, represente sur 12 bits, permet d'identifier ce paquet de 
maniere unique dans i'equipement qui est a I'origine du paquet de resolution 
d'adresse. 

Un champ denomme "management" ("gestion") et note 613, 
represente sur 20 bits, permet d'associer des informations a chaque 
1 5 enregistrement de la table selon le type de la table envisagee. 

Dans le cas d'une table de verification dite de "diffusion" (utilisee 
pour gerer la diffusion d'un paquet de resolution d'adresse de telle sorte que ce 
paquet soit transmis sur chaque bus du reseau, une et une seule fois), le 
champ "management" peut par exemple contenir une information indiquant si 
20 un paquet de resolution d'adresse a deja ete soit recu par I'equipement 
d'interconnexion ou "portal", soit transmis par ceiui-ci (une valeur booleenne 
peut par exemple etre suffisante). 

Dans le cas d'une table de verification dite de "reponse" (utilisee 
pour gerer la non-duplication d'une reponse vers I'equipement qui est a I'origine 
25 d'un paquet de resolution d'adresse), le champ "management" peut, par 
exemple, contenir une information indiquant si un paquet reponse a deja ete 
soit recu par I'equipement d'interconnexion ou "portal", soit transmis par celui-ci 
(une valeur booleenne peut par exemple etre suffisante). 

Selon une premiere variante non decrite ici, un compteur pourrait 
30 apporter des informations supplementaires sur le fait que plusieurs reponses, 
c'est-a-dire plusieurs descripteurs de chemin, existent et done qu'un choix 
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pourrait etre fait sur le descripteur de chemin a retenir selon des criteres 
predefinis comme, par exemple, le plus court chemin. 

Cette variante impose alors de definir un protocole de 
communication entre les differents equipements d'interconnexion ou "portals" 
afin d'effectuer le changement de descripteur de chemin a utiliser. 

Dans une deuxieme variante non decrite ici, c'est Talpha portal" 
qui centralise toutes les reponses recues au niveau du bus local 0C1 se situe 
I'equipement qui est a I'origine du paquet de resolution d'adresse, qui decide de 
retenir, selon des criteres predefinis comme, par exemple, le plus court chemin, 
un descripteur de chemin, et qui n'envoie finalement qu'un seul paquet reponse 
vers I'equipement qui est a I'origine du paquet de resolution d'adresse. 

- Une troisieme variante consiste a utiliser comme informations 
dans le champ "management", en plus de I'indicateur de passage de paquet de 
resolution d'adresse ou de paquet reponse deja transmis, une valeur indiquant 
par exemple la duree en unites de temps correctement definie ("timeout" en 
terminologie anglo-saxonne) au-dela de laquelle cet enregistrement n'est plus 
significatif et peut done etre detruit. 

Une quatrieme variante consiste a n'utiliser qu'une seule table de 
verification a la fois pour la "diffusion" et les "reponses". Dans ce cas, le champ 
"management" peut se decomposer entre deux champs, I'un contenant des 
informations relatives a la diffusion de paquet de resolution d'adresse, I'autre 
aux paquets reponses a ce paquet de resolution d'adresse. 

La figure 16 est une vue schematique de I'algorithme d'un precede 
de reception d'un paquet de resolution d'adresse au niveau d'un equipement 
d'interconnexion ou "portal" d'un pont. 

Les instructions ou etapes du procede sont stockees dans la 
memoire ROM de chaque pont du reseau. 

Au niveau du bus source, le paquet de resolution d'adresse emis 
par I'equipement source est decrit en reference a la figure 13. 

Ce paquet doit etre compris par les equipements d'interconnexion 
ou "portals" sources qui vont le traduire en un paquet de resolution d'adresse 
tel que represents sur la figure 13. 
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Au cours d'une etape 701, un paquet de resolution d'adresse est 
regu au niveau d'un equipement d'interconnexion ou "portal". Au cours de 
I'etape 702, les champs "EUI-64 source" et "sequencejiumber" decrits 
precedemment en reference a la figure 13 sont lus. 
5 Au cours de I'etape 703, le procede prevoit de verifier si un 

enregistrement elementaire ayant le numero EUI-64 source qui vient d'etre lu 
dans le paquet recu existe deja dans la table de verification 600, representee a 
la figure 15, a partir des champs EUI-64 source haut et bas presents dans cette 
table. 

10 Dans le cas ou I'enregistrement n'existe pas, au cours de I'etape 

704, le procede prevoit d'en creer un avec les valeurs des champs "EUI-64 
source" et "sequence_number" lus dans le paquet recu, par exemple 
I'enregistrement 601 represents a la figure 15, puis se poursuit par I'etape 709. 

Dans la cas ou I'enregistrement existe deja dans la table de 

15 verification, au cours de I'etape 705, le procede prevoit de v6rifier que le 
numero de sequence lu a partir du paquet recu est strictement superieur au 
numero de sequence courant de I'enregistrement, par exemple note 612 en 
figure 15. 

Dans le cas negatif (plus petit ou egal), lors de I'etape 706, le 
20 paquet de resolution d'adresse est ignore ; il se peut par exemple que ce soit 
un paquet plus ancien et qui, de toute facon, n'est plus valide. 

Dans le cas positif, le procede procede a une mise a jour du 
numero de sequence de I'enregistrement avec celui lu du paquet recu, au cours 
de I'etape 707, ainsi que des informations de gestion (comme celles 
25 precedemment mentionnees, telles que, par exemple, une valeur booleenne 
indiquant si un paquet de resolution d'adresse a deja transite sur le bus vu par 
I'equipement d'interconnexion ou "portal", et/ou un compteur indiquant combien 
de paquets identiques de resolution d'adresse ont ete detecte sur le bus vu par 
I'equipement d'interconnexion ou "portal", et/ou une valeur indiquant par 
30 exemple la duree en unites de temps correctement definie ("timeout" en 
terminologie anglo-saxonne) au-dela de laquelle cet enregistrement n'est plus 
significatif et peut done etre detruit), au cours de I'etape 708. 



56 



2794918 



Au cours de I'etape 709, le precede pr£voit de verifier si 
I'equipement d'interconnexion ou "portal" a connaissance de I'equipement 
recherche, identifie par les champs "Dev_EUI_64_hi" et "Dev_EUI_64Jo", 
notes respectivement 565 et 566 sur la figure 13. 
5 Autrement dit, dans le cas ou I'equipement recherche se situe sur 

le meme bus (ce bus est dit "bus destination") que I'equipement 
d'interconnexion ou "portal" en. question, alors ce dernier possede son numero 
EUI-64 dans une table interne qui n'est pas decrite dans ce contexte car elle est 
definie dans le cadre des specifications en cours du standard pont 1 394. 

10 Dans le cas positif, au cours de I'etape 710, le precede prevoit 

d'effectuer les operations de creation et/ou de mise a jour dans la table de 
routage precedemment decrite en reference aux figures 8 et 9, puis d'initier 
renvoi d'un paquet reponse 580, tel que decrit en reference a la figure 14, audit 
paquet de resolution d'adresse. 

15 Les champs de ce paquet reponse 580 sont notamment 

positionnes en utilisant les valeurs des champs du paquet de resolution 
d'adresse de la facon suivante : 

- le champ descripteur de chemin 561 est utilise pour positionner 
les champs 581, 582, 587 et 588, 

20 -le champ "response_packet_type_specific_information" 567 est 

utilise pour positionner le champ de meme nom 589, 

- le champ "sequence_number" 562 est utilise pour positionner le 
champ de meme nom 591 , 

- les champs "Src_EUI_64_hi" et "Src_EUI_64_lo" respectivement 
25 notes 563 et 564 sont utilises pour positionner les champs de memes noms 592 

et 593. 

Dans le cas negatif, au cours de I'etape 71 1 , le precede prevoit de 
verifier si I'equipement d'interconnexion ou "portal" a recu le paquet de 
resolution d'adresse du bus sur lequel il est situe (sinon cela signifie que le 
30 paquet a ete recu du (ou d'un) "portal" du pont auquel appartiennent ces 
"portals"). 
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Dans le cas positif (paquet recu du bus), le procede mis en oeuvre 
au niveau de I'equipement d'interconnexion ou "portal" prevoit d'envoyer, au 
cours de I'etape 712, le paquet a (aux) I' (les) equipement(s) d'interconnexion 
ou "portai(s)" constituant le pont. 
5 Dans le cas negatif (paquet recu de I'equipement d'interconnexion 

ou "portal"), le procede mis en ceuvre au niveau de I'equipement 
d'interconnexion ou "portal", au cours de I'etape 713, met a jour le descripteur 
de chemin du paquet de resolution d'adresse et I'envoie sur le bus, propageant 
ainsi la diffusion du paquet a travers le reseau de bus. 

10 Le descripteur de chemin ayant une taille finie, lorsque ce 

descripteur de chemin du paquet de resolution d'adresse ne peut plus elre mis 
a jour, la transmission ou diffusion dudit paquet de resolution d'adresse e_st 
stoppee. Ce traitement permet de controler le mecanisme de propagation du 
paquet de resolution d'adresse et, par la meme, permet de detecter et de 

15 resoudre les problemes de bouclage. 

Suite aux etapes 710, 712 et 713, le traitement du paquet de 
resolution d'adresse se trouve alors termine et le procede revient a son etape 
initiale (701 ) d'attente d'un nouveau paquet. 

La figure 17 est une vue schematique de I'aigorithme d'un procede 

20 de reception d'un paquet de donnees de reponse, suite a remission d'un 
paquet de resolution d'adresse, au niveau d'un equipement d'interconnexion ou 
"portal" d'un pont situe sur le bus ou se trouve I'equipement qui est a I'origine 
du paquet de resolution d'adresse. 

Les instructions ou etapes d'un tel procede sont stockees dans la 

25 memoire ROM du pont considere. 

La reception dim paquet de donnees de reponse peut revetir deux 
formes : soit il s'agit d'un paquet de donnees de reponse emis par un 
equipement d'interconnexion ou "portal" distant signifiant la presence de 
I'equipement recherche sur son bus, soit il s'agit d'un paquet de donnees de 

30 reponse emis par un equipement d'interconnexion ou "portal" local au bus 
source et, dans ce cas, il s'agit du seul et unique paquet envoye a I'equipement 
qui est a I'origine du paquet de resolution d'adresse. 



58 



2794918 



Au cours d'une etape 751, le precede mis en oeuvre au niveau de 
I'equipement d'interconnexion ou "portal" du bus ou se trouve I'equipement qui 
est a I'origine du paquet de resolution d'adresse, prevoit d'attendre un 
evenement associe a un paquet de reponse, c'est-a-dire ou bien la reception 
5 d'un paquet de reponse ou alors I'ecoulement d'une duree d'attente maximum 
predefinie depuis remission du paquet de resolution d'adresse. 

Au cours de I'etape suivante 752, le precede prevoit de verifier si 
I'ev6nement en question est effectivement un paquet de reponse au paquet de 
resolution d'adresse. 

10 Dans le cas positif, au cours de I'etape 753, le precede prevoit de 

verifier si le type du paquet de reponse recu est un paquet emis par un 
equipement d'interconnexion ou "portal" local au bus (paquet reponse unique 
envoye a I'equipement qui est a I'origine du paquet de resolution d'adresse). 

Dans le cas negatif, au cours de I'etape 754, le paquet de reponse 
15 est acquitte comme decrit dans le standard 1394-95 et le paquet de reponse 
etant base sur un paquet primaire asynchrone de type requ&e ("request" en 
terminologie anglo-saxonne), celui-ci doit etre acquitte par un paquet de type 
r6ponse ("response" en terminologie anglo-saxonne). 

Dans le cas negatif de la verification faite a I'etape 752, celle-ci est 
20 suivie par I'etape 760. 

Au cours de I'etape 755, le precede prevoit de verifier si un paquet 
de reponse pour le paquet de resolution d'adresse a deja ete recu par 
I'equipement d'interconnexion ou "portal" ou detecte sur le bus "source" ou si un 
acquittement negatif n'a pas deja ete genere sur le bus source. 
25 Dans le cas negatif ou, a priori, aucun paquet reponse n'est 

attendu, au cours de I'etape 758, le precede prevoit d'ignorer le paquet et de 
revenir a I'etape initiate 751 . 

Dans le cas positif, ou effectivement un paquet reponse est 
attendu, au cours de I'etape 756, le precede prevoit de memoriser la reception 
30 ou la detection d'un paquet reponse. 

Puis, au cours de I'etape 757, dans le cas ou le paquet reponse 
precedemment recu n'etait pas deja un paquet reponse unique envoye a 
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I'equipement qui est a I'origine du paquet de resolution d'adresse, le procede 
prevoit d'envoyer un paquet reponse unique a I'equipement qui est a I'origine 
du paquet de resolution d'adresse. 

Au cours de I'etape 760, le procede prevoit de verifier si la duree 
5 d'attente maximum predefinie s'est ecoulee depuis remission du paquet de 
resolution d'adresse. La duree d'attente doit etre correctement choisie, par 
exemple de telle sorte qu'elle soit superieure au temps du plus long parcdurs 
aller d'un paquet de resolution d'adresse additionne au temps de parcours de 
I'eventuel paquet r6ponse correspondant. Dans le cas negatif, le processus 

10 traite le cas d'erreur au cours de I'operation 761 . Dans le cas positif, I'etape 760 
est suivie d'une etape 762. 

Au cours de I'etape 762, si aucune operation n'a ete detectee sur 
le bus source, le procede prevoit d'envoyer a I'equipement qui est a I'origine du 
paquet de resolution d'adresse un paquet de reponse signalant qu'aucun 

15 equipement repondant au champ "EUI-64 source" precise dans le paquet de 
resolution d'adresse n'a ete trouve, et ce, pendant la duree d'attente maximum 
autorisee. Le procede prevoit ensuite de revenir a I'etape initiale 751 . 

La figure 18 est une vue schematique de I'algorithme d'un procede 
de gestion de la longueur des identificateurs de ponts ou labels de routage au 

20 niveau d'un bus en fonction de la capacite du bus. Les etapes ou instructions 
de ce procede sont stockees dans une memoire ROM d'au moins un des ponts 
relies au bus. 

II convient de noter que le pont considere relie deux parties d'un 
reseau entre elles, Tune des parties etant constitute du bus relie audit pont. 
25 Au cours d'une etape 901, le procede prevoit de detecter un 

evenement indiquant une premiere initialisation d'un bus auquel le pont est 
connecte. 

Au cours de I'etape 902, on determine pour ledit bus la capacite 
en bande passante (plus grande bande passante commune a tous les 
30 peripheriques presents sur ce bus). 

II convient de noter que la capacite en bande passante ou debit 
binaire du bus constitue une caracteristique de celui-ci. 
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Ensuite, au cours de I'etape 903, le proced6 prevoit de verifier, 
pour le bus, si la capacite dudit bus en bande passante est inferieure au debit 
binaire reference S400 par la norme 1394-95 (S400 signifiant un debit de 
393,216 Mbit/s). 

5 Dans le cas negatif, au cours de I'etape 904, il est verifie, pour le 

bus, si cette capacite du bus en bande passante est inferieure au debit 
reference S800 par le standard 1394-95 (S800 signifiant un debit de 786,432 
Mbit/s). 

Selon la valeur de la capacite en bande passante dudit bus, le 

10 procede prevoit de fixer, d'une part, la longueur en bits de I'identificateur ou 
label de routage au niveau dudit bus au cours des etapes 905, 907 et 909, puis, 
d'autre part, le nombre maximum de ponts ou d'equipements d'interconnexion 
de ponts ("portals") autorises sur ledit bus ("max_bridge" en terminologie anglo- 
saxonne), ceci au cours des etapes 906, 908 et 910. 

15 On notera que pour une longueur en bits de I'identificateur ou 

label de routage de n bits, seulement 2 n -1 valeurs d'identificateurs ou labels de 
routage sont autorisees car une valeur particuliere dite de separation (marqueur 
ou separateur) est reservee. 

Au cours de I'etape 911, on affecte un identificateur de routage 

20 constant et unique a I'equipement d'interconnexion ou "portal" du pont connecte 
au bus. Cette valeur d'identificateur de routage est avantageusement calculee 
de facon similaire par tous les equipements d'interconnexion ou "portals" a 
partir de la connaissance des identificateurs virtuels associes a chaque 
equipement d'interconnexion ou "portal" du bus considere. Par exemple, la 

25 valeur de I'identificateur de routage est definie pour chaque equipement 
d'interconnexion par ordre croissant de la valeur de I'identificateur virtuel et, 
ainsi, Halpha portal" se verra assigner un identificateur de routage de valeur '0'. 

Au cours de I'etape 912, le procede prevoit de verifier, pour le bus, 
si la valeur de I'identificateur de routage affecte a I'equipement d'interconnexion 

30 ou "portal" du pont en question est inferieure au nombre maximum de ponts 
autorises sur ledit bus. Dans le cas negatif, au cours de I'etape 914, le pont est 
positionne dans I'etat "desactive" ("disabled" en terminologie anglo-saxonne) et 
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I'algorithme se poursuit par l'etape 915 et une valeur particuliere representative 
de cet "etat" est definie pour I'identificateur de routage de I'equipement 
d'interconnexion ou "portal" considere. 

Par exemple, si le codage des identificateurs a lieu sur 3 bits, on 
5 ne peut pas identifier plus de sept ponts dans un champ d'informations 
d'identifications. 

Ainsi, si Ton connecte un huitieme pont au bus, celui-ci ne sera 

pas gere au niveau du bus et aucun identificateur de routage valide ne lui sera 

affecte (pont "desactive"). 
10 Dans le cas positif, au cours de I'etape 913, les differents 

parametres et variables permettant la mise en oeuvre du routage decrit dans le 

present document sont initialises. 

L'6tape 915 consiste a attendre un ev6nement de type 

initialisation de bus ("bus reset" en terminologie anglo-saxonne). 
1 5 Dans le cas ou cet ev6nement se produit, au cours de I'etape 916, 

I'algorithme verifie si la configuration des ponts au niveau du bus a chang6 (par 

exemple un pont a 6te nouvellement connects ou un pont existant a 6t6 

deconnecte). 

Dans le cas negatif, on revient a I'etape precedents 915. 
20 Dans le cas positif, au cours de I'etape 917, la mise en ceuvre du 

routage decrit dans le present document est suspendue de telle sorte que plus 
aucun paquet ne peut entrer sur le bus ou sortir de ce bus par I'intermediaire du 
pont. 

L'etape 918 consiste a attendre pendant une duree suffisante 
25 pred6finie ("time out" en terminologie anglo-saxonne) afin que tout p6riph6rique 
utilisant ce pont dans son descripteur de chemin pour communiquer avec un 
periph6rique "distant" considere ce descripteur de chemin comme obsolete. En 
consequence, le p6riph§rique doit par exemple generer a nouveau un paquet 
de resolution d'adresse avant de pouvoir reprendre toute communication. 
30 L'etape 902 est ensuite executee. 

Une autre variante, non decrite ici consiste, par exemple, pendant 
Tintervalle de temps entre la suspension de la mise en ceuvre du routage decrit 
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dans le present document (etape 917) et la revalidation de cette mise en ceuvre 
du routage, a acquitter d'une facon particuliere tout paquet desirant transiter via 
le pont. 

La figure 19 est une vue schematique de I'algorithme d'un precede 
5 de gestion de la longueur des identificateurs de ponts ou labels de routage au 
niveau d'un bus en fonction du nombre de ponts et done d'equipements 
d'interconnexion ou "portals" connectes au bus. Les etapes ou instructions de 
ce precede sont stockees dans une memoire ROM d'au moins un des ponts 
relies au bus. 

10 L'algorithme de ce precede ressemble fortement a celui decrit 

precedemment en reference a la figure 18, la difference portant principalement 
sur la caracteristique du bus utilisee pour decider de la longueur de 
I'identificateur ou label de routage a utiliser. 

Dans la figure 18, cette caracteristique est la capacite en bande 

15 passante ou debit binaire d'un bus donne, I'objectif etant d'eviter d'autoriser un 
trap grand nombre de communications transitant sur ledit bus. A cette fin, un 
pont est mis dans I'etat "desactive" pour qu'il ne puisse plus faire transiter 
d'information. On note que dans le precede de la figure 18, on cherche a 
prevenir toute congestion. 

20 Dans l'algorithme de la figure 19, la caracteristique du bus qui est 

prise en compte est le nombre de ponts ou d'equipements d'interconnexion ou 
"portals" connectes sur ledit bus. En fonction du nombre de ponts sur ledit bus, 
un certain nombre de bits est necessaire afin de pouvoir tous les identifier de 
fagon unique. 

25 Cet algorithme veille egalement a ne pas utiliser de bit inutilement 

pour cette identification. L'algorithme permet aussi de mettre un pont dans I'etat 
"desactive" dans le cas ou trap de bits sont necessaires pour I'identification 
dudit pont. 

D'autres variantes, non decrites dans le present document, 
30 peuvent aisement etre envisagees a partir d'autres caracteristiques d'une partie 
du reseau, par exemple un bus, qui seront prises en compte dans la decision 
d'affectation de la longueur de I'identificateur ou label de routage a utiliser. 
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Au cours d'une etape 951, on d6tecte un evenement indiquant une 
premiere initialisation d'un bus auquel le pont est connecte. 

L'etape 952, determine pour ledit bus le nombre de ponts ou 
d'equipements d'interconnexion ou "portals" presents sur ce bus. 
5 Ensuite, le proced6 prevoit de verifier, pour ce bus, si le nombre 

de ponts est inferieur a 3 au cours de l'etape 953, sinon s'il est inferieur a 7 au 
cours de l'etape 954 et sinon s'il est inferieur a 15 au cours de l'etape 955. 
Dans la negative, Palgorithme se poursuit par l'etape 965. 

Selon la valeur du nombre de ponts connectes audit bus, on fixe, 
10 d'une part, la longueur en bits de I'identificateur ou label de routage au niveau 
dudit bus au cours des 6tapes 956, 958 et 960, puis d'autre part, le nombre 
maximum de ponts ou d'equipements d'interconnexion ou "portals" autorises 
sur ledit bus ("max_bridge" en terminologie anglo-saxonne), ainsi que le 
nombre minimal d'equipements d'interconnexion ou "portals" pour ladite 
15 longueur en bits de I'identificateur ou label de routage ("min_bridge" en 
terminologie anglo-saxonne), ceci au cours des etapes 957, 959 et 961 . 

Au cours de l'etape 91 1 , on affecte un identificateur de routage 
constant et unique a I'equipement d'interconnexion ou "portal" du pont connects 
au bus. 

20 Cette valeur d'identificateur de routage est avantageusement 

calculee de facon similaire par tous les equipements d'interconnexion ou 
"portals", a partir de la connaissance des identificateurs virtuels assoctes a 
chaque equipement d'interconnexion ou "portal" du bus considered 

Par exemple, la valeur de I'identificateur de routage est definie 

25 pour chaque Equipement d'interconnexion par ordre croissant de la valeur de 
I'identificateur virtuel et, ainsi, ['"alpha portal" se verra assigner un identificateur 
de routage de valeur '0'. 

Au cours de l'etape 963, le precede prevoit de verifier, pour ledit 
bus, si la valeur de I'identificateur de routage affecte a I'equipement 

30 d'interconnexion ou "portal" du pont en question est inferieure au nombre 
maximum de ponts autorises sur ledit bus. 
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Dans le cas negatif, au cours de l'etape 965, le pont est positionn6 
dans I'etat desactive ("disabled" en terminologie anglo-saxonne) et une valeur 
particuliere representative de cet "etat" est definie pour I'identificateur de 
routage de I'equipement d'interconnexion ou "portal" considere, puis 
5 I'algorithme se poursuit par I'etape 966. 

Dans le cas positif, au cours de I'etape 964, les differents 
parametres et variables permettant la mise en oeuvre du routage decrit dans le 
present document sont initialises. 

L'etape 966 consiste a attendre un evenement de type 
10 initialisation de bus ("bus reset" en terminologie anglo-saxonne). Dans le cas ou 
cet evenement se produit, au cours de I'etape 967, I'algorithme verifie si la 
configuration des ponts au niveau du bus a change (par exemple un pont a 6t6 
nouvellement connecte ou un pont existant a ete deconnecte) et si le nombre 
de ponts ou equipements d'interconnexion ("portals") est en dehors de 
1 5 Nntervalle defmi pnScedemment par min_bridge et max_bridge. 

Dans le cas negatif, I'algorithme revient a I'etape precedente 966. 

Dans le cas positif, au cours de I'etape 968, la mise en ceuvre du 
routage decrit dans le present document est suspendue de telle sorte que plus 
aucun paquet ne peut entrer sur le bus ou sortir de ce bus par I'intermediaire 
20 dudit pont. 

L'etape 969 consiste a attendre pendant une dur6e suffisante 
predefinie ("time out" en terminologie anglo-saxonne) afin que tout p6riph6rique 
utilisant ce pont dans son descripteur de chemin pour communiquer avec un 
peripherique "distant" considere ce descripteur de chemin comme obsolete. En 
25 consequence, le peripherique doit par exemple regen£rer un paquet de 
resolution d'adresse avant de pouvoir reprendre toute communication. 

L'etape 952 est ensuite executee. 

II convient de remarquer que lorsqu'un pont relie entre elles deux 
parties d'un reseau, deux longueurs d'identificateurs differentes peuvent etre 
30 determinees respectivement pour les deux equipements d'interconnexion ou 
"portals" du pont considere en fonction de deux caracteristiques respectivement 
propres a chacune desdites deux parties du reseau. 
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Ainsi, dans un tel cas de figure, le marqueur qui delimite deux 
champs d'informations d'identification, respectivement du chemin a parcourir et 
parcouru par le paquet de donnees, voit sa taille ou longueur varier en 
consequence, afin que la difference de taille ou longueur entre les deux 
5 identificateurs des deux equipements d'interconnexion ou "portals" n'ait pas 
d'incidence sur la longueur totale du champ constitue du marqueur et des deux 
champs d'informations d'identification qui doit etre fixe. 

10 

La figure 20 est une vue schematique d'un reseau de 
communication note 1200 selon I'invention, de type conforme a la norme IEEE 
1394 et qui comporte plusieurs bus de communication serie conformes a la 
1 5 norme IEEE 1394 et dont seul certains sont references sur cette figure. 

Les bus de communication serie notes 1202 a 1218 sont 
interconnects deux a deux par des ponts dont seuls certains sont ref6rences 
sur la figure 20 et sont notes 1220 a 1232. 

II convient de noter que chaque pont de la figure 20 a par exemple 
20 Pallure du pont note entre parentheses 1226 et represents a la figure 3. 

Chaque pont comporte deux equipements d'interconnexion ou 
"portals" qui permettent respectivement de connecter les bus entre eux. 

Sur la figure 3, les elements du pont qui sont references 12, 14, 
16, 18, 20, 22, 24, 26, 28, 34, 36, 38, 40, 42 et 44 sont communs a chacun des 
25 Equipements d'interconnexion ou "portals" de ce pont et seuls les blocs de 
composants PHYLINK 1394 notes 30 et 32 sur cette figure sont specifiques 
respectivement a chaque equipement d'interconnexion. 

Ainsi, chaque equipement d'interconnexion d'un pont de la figure 
20 comporte un bloc de composants PHYLINK 1394 identique au bloc 30 ou 32 
30 de la figure 3, ainsi que les autres elements enonces ci-dessus et qui sont 
communs a chacun desdits equipements d'interconnexion. 
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Toutefois, dans certains cas, les equipements ^interconnexion ou 
"portals" d'un pont sont physiquement eloignes les uns des autres (cas d'une 
liaison radio) et chacun desdits equipements d'interconnexion comporte alors 
ses propres elements identiques a ceux enonces ci-dessus et notes 12 a 44. 
5 De maniere identique a ce qui est represente a la figure 3, les 

ponts notes 1220 a 1232 peuvent etre integres dans un appareil de traitement 
de donnees (par exemple un ordinateur) ou bien constituer eux-m6mes ledit 
appareil. 

Sur la figure 3, le pont 1226 est integre dans un ordinateur 1227. 
10 Les ponts representes a la figure 20 interconnectent chacun au 

moins deux parties du reseau 1200, lesdites parties etant, dans Pexemple 
represente sur cette figure, les bus de communication serie conformes a la 
norme IEEE 1394. 

Par aiileurs, des equipements de type peripherique dits applicatifs 
1 5 sont egalement relies aux bus de communication. 

Deux de ces equipements particuliers, notes 1240 et 1242 sont 
respectivement relies aux bus 1202 et 1218 de la figure 20. 

Ces peripheriques constituent respectivement ce que Ton appelle 
un peripherique source, note 1240, et un peripherique destinataire, note 1242. 
20 Ces deux pe>ipheriques sont relies a des bus eloignes Tun de 

I'autre et qui sont separes par plusieurs ponts. 

Les ponts notes 1220 et 1221 sur la figure 20 constituent des 
ponts dits d'extremites et ceux-ci sont s6pares Pun de I'autre par plusieurs ponts 
appeles pont intermediates et notes 1222, 1224, 1226, 1228, 1230 et 1232. 
25 Les ponts d'extremites notes 1220 et 1221 constituent, au sens de 

I'invention, un premier et un deuxieme ponts d'extremites, le premier pont 
d'extremite etant celui a partir duquel un paquet de donnees de type requete 
est emis sur le reseau. 

Dans le cas represente a la figure 20, le pont note 1220 est 
30 qualifie de pont "source" et le pont note 1221 est qualifie de pont "destinataire". 
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Parmi les ponts intermediaires represents a la figure 20, deux 
d'entre eux notes 1226 et 1232 constituent ce que I'on appelle, au sens de 
I'invention, des ponts "relais". 

La definition de ces ponts sera donnee ulterieurement. 
5 Selon un premier mode de realisation, lorsque le peripherique 

source 1240 souhaite communiquer un paquet de donnees au peripherique 
destinataire 1242 (figure 20) et qu'il ne connaTt pas encore le chemin que le 
paquet de donnees doit emprunter pour parvenir a destination, alors on utilise le 
mecanisme d'etablissement d'un chemin dans le reseau decrit en reference aux 
10 figures 12 a 17. 

Ce mecanisme est base sur remission par le peripherique source 
d'un paquet de donnees de resolution d'adresse conforme a la norme IEEE 
P1394a (paquet "GASP"). 

Les ponts sources ont pour role de transformer ce paquet de 
15 resolution d'adresse en un paquet de resolution d'adresse dont la structure est 
celle representee a la figure 13 et qui est diffuse dans tout le reseau de 
communication 1200. 

Ce paquet de resolution d'adresse, une fois regu au niveau du 
pont destinataire, declenche remission d'un paquet dit de reponse au paquet de 
20 resolution d'adresse qui est retourne au peripherique source de la facon 
indiquee dans la description faite en reference aux figures 12 a 17. 

La figure 21 illustre de maniere tres schematique le cheminement 
d'un paquet de donnees de resolution d'adresse a partir du pont source 1220 
jusqu'au pont destination note 1221. 
25 Ce paquet "note 1250 au niveau du pont source 1220 est 

successivement reper6 par les references 1252 et 1253 "au niveau, 
respectivement des ponts relais 1226 et 1232. 

Sur la partie droite de la figure 21 , une vue tres schematique d'une 
table de routage analogue a celle de la figure 8 est representee en regard de 
30 chaque pont dont elle fait partie. 

Plus particulierement, chacune des tables de routage comporte 
plusieurs enregistrements eiementaires analogues a ceux represent.es par les 
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references 250 a 259 sur la figure 8 et dont un seul est represents sur la figure 
21 pour chacune desdites tables. 

Chaque enregistrement elementaire d'une table de routage 
comporte les champs references 270, 271 et 272 sur la figure 8 et une partie du 
5 champ note 271, denomme "activ", est reservee a deux champs 
supplementaires notes respective ment "index" et "Bridge Type". 

Les tables de routage contenues dans chacun des ponts 1220, 
1226, 1232 et 1221, sont respectivement referencees 1260, 1262, 1264 et 
1266. 

10 Dans les tables de routage notees 1262, 1264 et 1266, 

I'enregistrement elementaire qui est utilise pour illustrer le principe de la 
presente invention est respectivement note 1263, 1265 et 1267. 

La table de routage notee 1260 n'est pas utilisee dans la 
description faite en reference a la figure 21, mais le sera dans la description 

15 faite en reference a la figure 23 qui correspond au transfert dans le reseau d'un 
paquet de reponse audit paquet de resolution d'adresse. 

Chaque paquet de resolution d'adresse comporte au moins un 
champ d'informations de longueur predeterminee qui est reserve a des 
informations d'identification d'un chemin pour le paquet dans le reseau, ainsi 

20 qu'un champ supplemental reserve a un index. 

Ces informations d'identification du chemin du paquet dans le 
reseau represented le descripteur de chemin denomme "path descriptor" en 
terminologie anglo-saxonne et qui est represente sur les figures 8 et 13. 

Ce descripteur de chemin comporte en fait un ensemble de trois 

25 champs d'informations : un premier champ d'informations qui represente les 
informations d'identification du chemin a parcourir par le paquet de donnees 
pour parvenir a sa destination (champs notes 201 , 202 dans le paquet 199 de la 
figure 5), un deuxieme champ qui represente les informations d'identification du 
chemin parcouru par le paquet dans le reseau (champs notes 206, 207, 208 

30 dans le paquet de donnees 199 de la figure 5) et un troisieme champ appele 
marqueur qui separe les premier et deuxieme champs I'un de I'autre (champs 
notes 200 et 205 dans le paquet 199 de la figure 5). 
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Les mecanismes de traitement conformations ayant lieu entre les 
premier et deuxieme champs ail sein d'un meme paquet de donnees, qui sont 
decrits en reference aux figures 1 a 17 et concernent, au niveau de chaque 
pont, respectivement la suppression d'une information dans le premier champ 
5 et I'ajout d'une information dans le deuxieme champ, sont repris dans la 
description de la presente invention. 

II convient de noter que dans les paquets de resolution d'adresse 
representes sur la figure 21 le champ descripteur de chemin est illustre de 
maniere tres schematique au niveau de chaque paquet note 1250, 1252 et 
10 1253 par un bloc reference respectivement 1250a, 1252a et 1253a. 

II convient egalement de noter que les mecanismes decrits en 
reference a la figure 1 1 concernant te routage d'un paquet au niveau d'un pont 
et qui consistent notamment a determiner si le pont au niveau duquel se trouve 
un paquet de donnees est considere comme le pont destination sont egalement 
15 repris dans le cadre de la description de la presente invention. 

La description de la figure 21 va etre faite en reference a la figure 
22 qui represente un algorithme sur lequel est base le procede de traitement 
d'un paquet de donnees selon I'invention et qui est mis en ceuvre au niveau de 
chaque pont, notamment les ponts dits relais du reseau de communication 
20 selon I'invention. 

Les differentes instructions ou etapes de ce procede font partie 
d'un programme informatique stocke dans la memoire ROM de chaque pont qui 
est analogue a la memoire ROM du pont de la figure 3. 

Lors de la reception d'un paquet au niveau d'un pont, ('unite de 
25 calcul CPU de chaque equipement d'interconnexion ou "portal" ou de chaque 
pont, lorsque I'unite de calcul est partagee par les equipements 
d'interconnexion comme represente a la figure 3, execute le programme stocke 
dans la memoire ROM et sur lequel est base Talgorithme de la figure 22. 

Lors de remission du paquet de donnees de resolution d'adresse 
30 1250 par le pont source 1220, le champ 1250a du descripteur de chemin est 
representatif du chemin parcouru et contient deja I'identificateur de routage de 
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I'equipement d'interconnexion ou "portal" par lequel le paquet est emis sur le 
reseau. 

II convient egalement de noter que le paquet de donnees de 
resolution d'adresse 1250 comporte 6galement un champ denomme "index" 
5 note 1250b et qui est par exemple contenu dans le champ note 568 et 
denomme "reserved" du paquet de resolution d'adresse 550 de la figure 13. 

Le paquet de resolution d'adresse 1250 est emis a travers le 
reseau de communication 1200 selon I'invention et est transfere par les ponts 
intermediaires 1222 et 1224 avant de parvenir au pont intermediaire 1226 
1 0 egalement appele premier pont relais. 

Lors du transfert de ce paquet de donnees par les ponts 
intermediaires 1222 et 1224, le champ descripteur de chemin dudit paquet qui 
est rempli par ajout des informations d'identification du chemin retour 
permettant d'aller du pont relais 1226 au pont source 1220. 
15 Ces informations concement les identificateurs de routage des 

equipements d'interconnexion ou "portals" par lesquels le paquet quitte chacun 
des ponts interm6diaires. 

Compte tenu du nombre de bits necessaire pour coder 
I'identificateur de chaque equipement d'interconnexion d'un pont et du nombre 
20 de ponts presents sur chaque bus, ainsi que de la capacite de stockage limitee 
des champs d'informations d'identification du paquet, lorsque celui-ci est 
receptionne au niveau du pont relais 1226, la taille ou longueur predeterminee 
du champ d'informations d'identification du chemin parcouru par le paquet de 
donnees est occupee en totalite dans ledit paquet par les informations qui 
25 viennent d'etre ajoutees (chemin complet) ou ne permet plus de stacker aucune 
information de routage elementaire. 

Cette condition determine le fait que le paquet de donnees de 
resolution d'adresse 1250 se situe au niveau d'un pont appele pont relais. 

A ce niveau, le paquet de resolution d'adresse ne peut 
30 normalement plus poursuivre son chemin puisque la place laissee libre pour y 
inscrire les informations d'identification du chemin parcouru est occupee ou du 
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moins n'est plus suffisante pour stocker une information de routage 
elementaire. 

La presente invention vise justement a remedier a ce probleme. 

L'algorithme represents a la figure 22 est mis en oeuvre au niveau 
5 de chaque pont, mais il ne sera decrit que lorsqu'il est mis en oeuvre au niveau 
d'un pont relais par souci de simplification. 

Ainsi, au niveau du pont relais 1226, lors de la reception du 
paquet de donnees 1250 de la figure 21, le procede selon I'invention prevoit 
une etape 1270 d'analyse du type de paquet de donnees regu. 
10 Si le paquet recu n'est pas un paquet de resolution d'adresse, 

alors il est prevu de se placer en attente de reception d'un nouveau paquet de 
donn6es (le paquet regu sera traite par un autre algorithme, decrit 
ulterieurement). 

Au contraire, si le paquet regu est un paquet de resolution 
15 d'adresse, comme c'est le cas du paquet 1250, alors I'etape 1270 est suivie 
d'une etape 1272 au cours de laquelle il est effectue un test quant a savoir si le 
descripteur de chemin est complet. 

Ce test est realise en detectant que I'espace utilise pour 
memoriser le chemin parcouru est occupe en totalite ou n'est plus suffisant pour 
20 y stocker une information de routage elementaire. 

Dans la negative, cela signifie que le paquet a ete regu par un 
pont intermediaire qui n'est pas un pont relais, comme par exemple les ponts 
notes 1222 et 1224 sur la figure 20, et alors I'etape 1272 est suivie d'une etape 
1274 au cours de laquelle le paquet de donnees est traite de maniere 
25 appropriee par le pont intermediaire en question. 

Ce traitement est effectue comme indique dans la description faite 
en reference aux figures 1 1 et 16. 

Le paquet est ensuite transmis au pont intermediaire suivant. 
Au contraire, si le descripteur de chemin est complet, alors I'etape 
30 1272 est suivie d'une etape 1276 au cours de laquelle il est verifie s'il existe 
dans la table de routage notee 1262 sur la figure 21 un enregistrement 
correspondant au descripteur de chemin retour. 
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Dans I'affirmative, il est prevu une etape 1278 de mise a jour de 
reformation de gestion contenue dans le champ denomme "activ" note 271 de 
la table de routage de la figure 8. 

Cette etape de mise a jour est plus particulierement explicitee 
5 dans la description faite en reference aux figures 8 et suivantes. 

Le champ "activ" peut egalement etre utilise pour indiquer la dur§e 
au-dela de (aquelle I'enregistrement n'est plus significatif. 

De retour a I'etape 1276, si cet enregistrement correspondant au 
chemin parcouru par le paquet jusqu'au pont considere n'existe pas dans le 
10 table de routage 1262, alors I'algorithme comporte une etape 1280 au cours de 
laquelle un test est pratique quant a savoir si le pont consider est un pont 
destination. 

Dans le cas present, le paquet est au niveau du pont relais 1226 
et I'etape 1280 est done suivie d'une etape 1282 au cours de laquelle la 
15 variable "Bridge Type" est mise a 1, ce qui signifie que le pont est un pont dit 
relais. 

L'etape suivante notee 1284 consiste a lire dans le paquet de 
donnees de resolution d'adresse 1250, d'une part, les informations 
d'identification du chemin parcouru par ledit paquet de donnees et 
20 correspondant au chemin retour et, d'autre part, un eventuel index. 

Dans le cas present, cet index est fix6 a la valeur nulle comme 
represents dans le bloc note 1250b (figure 21), car il s'agit du premier pont 
relais. 

Lors de I'etape 1284, le procede prevoit egalement d'allouer une 
25 zone m£moire structured ou enregistrement note 1263 de la table de routage 
1262 et de recup6rer un index note bO et qui polnte sur la zone m6moire 
consideree. 

Le proc6de pr£voit ensuite d'ecrire dans cette zone m£moire 
structured ou enregistrement des informations. Les informations representatives 
30 du chemin parcouru jusqu'au pont relais 1226 (chemin retour) denomme 
"backward_0" sont ecrites dans le champ note 1263a, I'eventuel index qui vient 
d'etre lu est ecrit dans le champ note 1263b et la variable "Bridge Type" qui 
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vient d'etre determinee a Petape 1282 est ecrite dans le champ note 1263c de 
Penregistrement 1263. 

Dans toute la suite de la description et notamment celle faite en 
reference aux figures 23 a 27, on utilisera de preference le terme 
5 d'enregistrement a la place de celui de zone memoire structuree et Petape 
d'allocation d'une zone memoire structuree sera le plus souvent remplacee par 
une etape de creation d'un enregistrement. 

L'etape 1284 est alors suivie de Petape 1278 decrite ci-dessus et 
d'une etape ulterieure 1286. 

10 Au cours de cette etape 1286, il est procede a Peffacement des 

informations representatives du chemin parcouru par le paquet 1250 du pont 
1220 au pont relais 1226 dans ce dernier, afin de liberer la place disponible 
pour stacker d'autres informations d'identification du chemin parcouru par le 
paquet de donnees lors de sa future progression dans le reseau. 

15 Le paquet de donnees de resolution d'adresse qui va etre 

prochainement emis par le pont relais 1226 est note 1252 et comporte le bloc 
note 1252a contenant I'information de descripteur de chemin qui, ici, contient 
deja Pidentificateur de routage de I'equipement d'interconnexion ou "portal" par 
lequel le paquet est emis sur le reseau. 

20 Au cours de Petape 1286, il est egalement procede a I'ecriture de 

la valeur de I'index bO recupere precedemment dans le paquet de resolution 
d'adresse 1252 a Pemplacement prevu a cet effet et represents par le champ 
1252b. 

II convient de noter que I'index bO qui reference Penregistrement 
25 1263 contenant le champ 1263a representatif du chemin parcouru par le paquet 
depuis le pont source jusqu'au pont relais 1226 permettra ulterieurement de 
retrouver au niveau de ce pont relais ces informations d'identification du chemin 
de retour jusqu'au pont source. 

Le paquet 1252 est ensuite envoye dans le reseau de 
30 communication et est transfere par les ponts intermediates 1228 et 1230 avant 
de parvenir au deuxieme pont relais 1232. 
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II convient de noter qu'au niveau des ponts intermediates notes 
1228 et 1230, le programme informatique contenu dans la memoire ROM de 
chacun des ces ponts et dont I'algorithme est celui de la figure 22 est mis en 
ceuvre a chaque reception du paquet de resolution d'adresse note 1252. 
5 Toutefois, etant donne que le descripteur de chemin de ce paquet 

de donnees n'est pas complet au niveau de chacun de ces ponts, seules les 
etapes 1270, 1272 et 1274 de I'algorithme sont executees. 

Dans I'exemple represents sur la figure 21 , le paquet de resolution 
d'adresse 1252 est regu par le pont relais 1232 et les etapes successives 1270, 
10 1272, 1276, 1280, 1282 et 1284 de I'algorithme de la figure 22 sont alors 
executees. 

Au cours de I'etape 1284, il est prevu de lire dans le paquet 1252 
le champ d'informations de longueur predeterminee qui contient les 
informations d'identification du chemin parcouru par ledit paquet entre le 

15 premier pont relais 1226 et le deuxieme pont relais 1232 (chemin retour) ainsi 
que Pindex bO recupere au niveau du premier pont relais. 

Une zone memoire structuree ou enregistrement 1265 est alors 
alloue dans la table de routage 1264 du deuxieme pont relais 1262 et un index 
bi referengant cet enregistrement dans ladite table est recupere. 

20 Au cours de cette meme etape 1284, il est egalement prevu 

d'ecrire dans un champ note 1265a de I'enregistrement 1265 les informations 
representatives du chemin parcouru par le paquet entre les premier et 
deuxieme ponts relais etdenommees "backward_1". 

Cet enregistrement comporte egalement deux autres champs 

25 notes 1265b et 1265c qui contiennent chacun respectivement I'index bO 
recupere au niveau du premier pont relais et la variable "Bridge Type" mise a 1. 

L'etape 1284 est suivie de I'etape 1278 ainsi que d'une etape 
1279 au cours de laquelle un test est effectue sur la valeur de la variable 
"Bridge Type" par rapport a a valeur "0". 

30 Si le resultat du test s'avere positif, cela signifie que le paquet est 

au niveau d'un pont destination et I'etape 1279 est suivie d'une etape 1281 au 



75 



2794918 



cours de laquelle I'unite de calcul CPU execute I'algorithme de la figure 16 
avant de se placer en attente de reception d'un autre paquet. 

Si le resultat du test s'avere negatif, I'etape 1279 est suivie de 
I'etape ulterieure 1286 au cours de laquelle les informations denomm^es 
5 "backward_1" sont effacees du champ descripteur de chemin du paquet de 
resolution d'adresse 1252. 

Ainsi, la place occupee par ces precedentes informations est 
mainteriant liberee pour venir y stacker de nouvelles informations d'identification 
du chemin parcouru par le paquet de donnees de resolution d'adresse, chemin 
10 qui sera elabore lors de la progression de ce paquet a travers les ponts 
suivants. 

Ces nouvelles informations d'identification de chemin seront 

stockees dans un bloc du paquet de resolution d'adresse 1253 qui va §tre emis 

par le pont relais 1232 au niveau d'un champ d'un bloc note 1253a. 
15 L'etape 1286 prevoit egalement d'ecrire la valeur de I'index b1 

precedemment recuperee dans le paquet de donnees de resolution d'adresse 

1253, et plus particulierement au niveau d'un champ note 1253b. 

Le paquet de resolution d'adresse 1253 est alors diffuse sur le 

reseau en direction du pont destination 1221. 
20 Au niveau de ce pont un traitement approprie effectue sur le 

paquet de resolution d'adresse 1253 permet de determiner que celui-ci est 

arrive sur le pont destination. 

On se rapportera a cet effet a la description faite en reference aux 

figures 9 a 1 1 pour de plus amples informations concernant ce. 
25 II convient de noter que ce traitement est 6galement effectue au 

niveau de chacun des ponts intermediates rencontres par le paquet sur son 

chemin. 

Au niveau de ce pont, les etapes successives 1270, 1272 et 1276 
de I'algorithme de la figure 22 sont de nouveau executees et comme le pont 
30 rencontre est un pont destination, I'etape suivante notee 1280 conduit a I'etape 
ulterieure notee 1288 au cours de laquelle la variable "Bridge Type" est mise a 
la valeur 0. 
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L'etape suivante 1284 de I'algorithme sur lequel est bas6 le 
precede selon I'invention prevoit de lire dans le paquet de resolution d'adresse 
1253 recu des informations representatives du chemin parcouru par ledit 
paquet depuis le pont relais 1232 jusqu'au pont destination 1221, ainsi que la 
5 valeur de I'index note b1 et creee au niveau dudit pont relais 1232. 

Un enregistrement 1267 est alors cree dans la table de routage 
1266 du pont destination 1221 et un index note b2 referengant cet 
enregistrement est recuperet 

L'execution de I'algorithme par I'unite de calcul CPU du pont 
10 consider^ provoque I'ecriture dans I'enregistrement note 1267 des informations 
d'identification du chemin retour denomm6es "backward_2" dans un champ 
note 1267a de la valeur de I'index b1 lue dans le paquet 1253 et de la valeur de 
la variable "Bridge Type" mise recemment a la valeur 0 dans deux champs 
respectifs notes 1267b et 1267c. 
1 5 L'etape 1 284 est alors suivie de l'etape 1 278. 

Le paquet est ensuite envoye apres un traitement approprie tel 
que decrit en reference aux figures 11 et 16 sur le bus de communication s6rie 
auquel est connects le periph£rique destination 1242. 

Etant donn£ que le paquet de resolution d'adresse qui s'est 
20 propage dans le reseau par diffusion a atteint le pont destination qui possede la 
connaissance du p£riph6rique destination, il faut maintenant emettre a 
destination du pont source et du peripherique source un paquet dit de r6ponse 
au paquet de resolution d'adresse precedent. 

La description qui va suivre faite en reference aux figures 23 et 24 
25 concerne le cheminement d'un tel paquet depuis le pont destination jusqu'au 
pont source. 

Le paquet de donnees asynchrone de reponse au paquet de 
resolution d'adresse precedemment decrit a la structure representee sur la 
figure 14 sur laquelle, par exemple, le champ "reserved" note 590 est utilise 
30 pour stocker I'index supplementaire 1290c, 1312c et 1316c. 

II convient de noter que les deux index contenus dans chaque 
paquet de donnees asynchrone represents a la figure 23 peuvent se trouver 
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tous les deux dans le champ "reserved", ou l'un seulement dans ce champ et 
I'autre dans un autre champ crSS a cet effet, ou encore tous les deux dans deux 
champs distincts prevus a cet effet. 

Sur la figure 23, les parties grisees situSes dans les paquets de 
5 donnees, d'une part, se rapportent aux index supplementaires 1290c, 1312c et 
1316c et, d'autre part, dans les tables de routage, font reference aux 
informations representatives du chemin retour et qui ont ete positionnees lors 
du cheminement du paquet de resolution d'adresse. 

Sur la figure 23 on a represents un paquet de donnees 
10 asynchrone Smis par le pont destination 1221 en reponse au paquet de 
resolution d'adresse 1253 represents sur la figure 21 . 

Ce paquet de reponse note 1290 porte un champ descripteur de 
chemin note 1290a qui contient I'information stockee dans le champ 1267a de 
I'enregistrement elementaire 1267 qui est points par I'index b2, un champ 
15 1290b contenant I'index b1 qui etait stocks dans le champ 1267b de 
I'enregistrement elementaire 1267 et un champ note 1290c contenant I'index b2 
lui-meme. 

L'information contenue dans le champ descripteur de chemin 
1290a permet au paquet de reponse 1290 de remonter dans le reseau jusqu'au 
20 pont relais 1232. 

Le paquet de reponse 1290, recu au niveau du pont relais 1232, 
est traits au niveau dudit pont conformSment au procede de reception d'un 
paquet de reponse a un paquet de resolution d'adresse selon I'invention en 
tenant compte, bien entendu, des particularites propres a la gestion des index. 
25 Le procede selon I'inverition est base sur un algorithme represents 

a la figure 24 et qui est mis en oeuvre au niveau de chaque pont du reseau de 
communication 1200 de la figure 20. 

Les differentes instructions ou Stapes de ce procede font partie 
d'un programme informatique stocke dans la memoire ROM de chacun de ces 
30 ponts, memoire qui analogue a la memoire ROM du pont 1226 represents sur 
la figure 3. 
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A la reception du paquet de reponse 1290, I'unite de calcul CPU 
du pont relais 1232, execute le programme stocke dans la memoire ROM de ce 
pont, comme represents a la figure 3, et sur lequel est base I'algorithme de la 
figure 24. 

5 L'algorithme de la figure 24 comporte, tout comme celui de la 

figure 22, des etapes notees, pour la figure 24, 1292, 1294, 1296, 1298 et 1300 
qui sont respectivement identiques aux Stapes 1270, 1272, 1274, 1276 et 1278 
de la figure 22 et ne seront done pas reprises dans le cadre de la presente 
description. 

10 II convient de noter que le test effectuS a I'etape 1294 consiste a 

determiner si le chemin a parcourir est vide. 

Le procedS selon I'invention prevoit une etape 1302 consecutive a 

I'etape 1298 et au cours de laquelle il est verifiS si le pont au niveau duquel est 

recu le paquet de reponse est un pont source. 
15 Pour ce faire, il est procSde a un test sur la valeur de I'index 

contenu dans le champ 1290b. 

Dans le cas present, cette etape est suivie de I'etape 1304 

analogue a I'etape 1282 de la figure 22 au cours de laquelle la variable "Bridge 

Type" est mise a la valeur 1 . 
20 Le precede comporte egalement une etape 1306 au cours de 

laquelle un enregistrement elementaire note 1308 est creS dans la table de 

routage 1264 du pont relais 1232 et un nouvel index note f2 pointant sur cet 

enregistrement est recuperet tel que represents a la figure 23. 

L'Stape 1306 comporte egalement une operation de lecture dans 
25 le paquet de reponse 1290 du descripteur de chemin contenu dans le champ 

1290a et de I'index b1 contenu dans le champ 1290b, ainsi que I'index notS b2 

contenu dans le champ 1290c. 

Le descripteur de chemin denomme "backward_2" identifiant le 

chemin a parcourir par le paquet 1290 depuis le pont destination 1221 jusqu'au 
30 pont relais 1232 est consomme au fur et a mesure de la progression dudit 

paquet dans le reseau et, par le biais du mecanisme decrit en reference aux 

figures 1 a 1 1 , il se transforme, au niveau du pont relais 1232, en descripteur du 
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chemin parcouru par le paquet 1290 entre le pont destination 1221 et le pont 
relais 1232 et qui est a parcourir pour parvenir du pont relais 1232 au pont 
destination 1221. 

Ce nouveau descripteur de chemin obtenu lorsque le paquet 1290 
5 est receptionne au niveau du pont relais 1232 est denomme "forward_2". 

Au cours de I'etape 1306 du procede selon I'invention, il est 
ensuite prevu d'ecrire dans I'enregistrement 1308 de la table de routage 1264 le 
nouveau descripteur du chemin d6nomm6 "forward_2" dans un champ note 
1308a dudit enregistrement elementaire, la valeur de I'index b2 lue dans le 
10 paquet de donnees dans un champ note 1308b et la valeur 1 de la variable 
"Bridge Type" dans un champ 1308c de ce mSme enregistrement elementaire. 

L'etape 1306 est ensuite suivie de I'etape 1300 et d'une etape 
1301 au cours de laquelle un test est effectue sur la valeur de la variable 
"Bridge Type" par rapport a la valeur "0". 
15 Si le resultat de ce test est positif, cela signifie que le paquet est 

au niveau d'un pont source et I'etape 1301 est suivie d'une etape 1303 au cours 
de laquelle I'unite de calcul CPU execute I'algorithme represents a la figure 17. 

Si le rSsultat est negatif, I'etape 1300 est suivie de I'etape 
ulterieure 1310 au cours de laquelle on procede a une lecture, dans 
20 I'enregistrement elementaire 1265, du prochain descripteur de chemin 
denomme "backward_1" determine precedemment, en reference a la figure 21 
au niveau du pont relais 1232. 

Ce descripteur de chemin contient des informations d'identification 
du chemin a parcourir par le paquet pour parvenir du pont relais 1232 au pont 
25 relais 1226. 

On procede Sgalement a une lecture dans cet enregistrement de 
la valeur du prochain index note bO qui a egalement ete determine au niveau du 
pont relais 1232 en reference a la figure 21. 

L'Stape 1310 comporte egalement une operation d'ecriture dans le 
30 paquet de reponse note 1312 destine a etre emis sur le reseau du prochain 
descripteur de chemin denomme "backward_1 ", plus particulterement dans un 
champ 1312a dudit paquet. 
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On precede egalement a l'6criture du prochain index bO dans un 
champ note 1312b, ainsi que du nouvel index f2 dans un champ note 1312c et 
qui permettra au futur paquet arrivant au niveau du pont relais de retrouver 
dans la table de routage 1264, le descripteur de chemin "forward_2" qui 
5 identifie le chemin a parcourir pour aller dudit pont relais 1232 au pont 
destination 1221. 

Le paquet de reponse 1312 est ensuite emis par le pont relais en 
direction du prochain pont relais 1226. 

De fagon analogue a ce qui vient d'etre decrit pour le paquet 1290 
10 et le paquet 1312 au niveau du pont relais 1232, le pont relais 1226 procede au 
meme traitement du paquet de reponse 1312 lors du transfert de ce paquet par 
led it pont.- 

Les etapes de I'algorithme de la figure 24 qui sont executes au 
niveau du pont relais 1226 sont les memes que celles executees au niveau du 

15 pont relais 1232. 

Ainsi, une zone memoire structured ou enregistrement 
elementaire 1314 comportant trois champs 1314a, 1314b et 1314c est allou6 
dans la table de routage 1262 du pont relais 1226 et un nouvel index f1 pointant 
sur cet enregistrement est r6cup6re. 

20 Dans cet enregistrement, on trouve dans le champ 1314a le 

descripteur de chemin denomm6 "forward_1" correspondant au chemin a 
parcourir par un paquet de donn6es pour parvenir du pont relais 1226 au pont 
relais 1232 et qui a ete elabor6 lors de la progression du paquet de donnees 
1312 vers le pont relais 1226 par consommation du descripteur de chemin 

25 denomme "backward_1" dudit paquet 1312. 

Le descripteur de chemin denomme "backward_0" determin6 
precedemment en reference a la figure 21 au niveau du pont relais 1226 est 
ecrit dans le paquet reponse 1316 au niveau d'un champ note 1316a. 

La valeur nulle de I'index stockee dans le champ 1263b determine 

30 precedemment en reference a la figure 21 est ecrite dans un champ 1316b du 
paquet 1316 et I'index f1, est egalement 6crit dans un champ note 1316c du 
paquet de reponse 1316. 
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Cet index permet de retrouver, au niveau du pont relais 1226, 
directement, le chemin a parcourir pour parvenir du pont relais 1226 au pont 
relais 1232, via le descripteur de chemin "forward_1", et indirectement, le 
chemin a parcourir pour parvenir du pont relais 1232 au pont destination 1221, 
5 par I'intermediaire de I'index f2. 

Ainsi, les index f1 et f2 permettent de retrouver les informations 
d'identification du chemin a parcourir par un paquet de donnees sur le r6seau 
pour parvenir du pont relais 1226 au pont destination 1221 . 

Le paquet de reponse 1316 est ensuite emis sur le reseau en 
10 direction du pont source 1220 et la progression dudit paquet vers le pont source 
permet, par la consommation du descripteur de chemin "backward_0", 
d'elaborer le chemin de retour denomme "forward_0" qui, ajout6 aux 
descripteurs de chemin pr6c6dents denomm6s "forward_1" et "forward_2" 
identifie le chemin a parcourir par un paquet de donnees issu du pont source et 
1 5 destine au pont destination 1221 . 

Lorsque le paquet de reponse 1316 est recu par le pont source 
1220, I'unite de calcul CPU dudit pont execute I'algorithme de la figure 24 et 
plus particulierement les etapes 1292, 1294, 1298 et 1302. 

Etant donne que le paquet de reponse 1316 est arrive au niveau 
20 du pont source, alors I'etape 1302 est suivie d'une etape 1318 au cours de 
laquelle la variable "Bridge Type" est mise a la valeur 0. 

De facon analogue a ce qui vient d'etre decrit au niveau des ponts 
relais 1226 et 1232, un enregistrement elementaire 1320 est cree dans la table 
de routage 1260 du pont source 1220, et est reference^ par I'index note fO 
25 pointant sur cet enregistrement. 

Cet enregistrement contient trois champs 1320a, 1320b, 1320c qui 
contiennent respectivement le descripteur de chemin qui vient d'etre elabore 
denomme "forward_0", I'index f1 provenant du paquet 1316 et la valeur 0 de la 
variable "Bridge Type". 
30 Au niveau du pont source 1220, I'unite de calcul CPU de ce pont 

execute I'algorithme de la figure 17. 
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Lorsque le chemin permettant a un paquet de donndes issu du 
periph6rique source 1240, de parvenir du pont source 1220 au pont destination 
1221 est etabli, alors on procede a remission d'un paquet de donnees 
asynchrone sur le r6seau a destination du p6ripherique 1242, comme 
5 represents a la figure 25. 

Selon un deuxieme mode de realisation, le transfert d'un paquet 
de donnees asynchrone a travers le rSseau de communication selon I'invention 
va maintenant etre decrit en reference a la figure 25 et a la figure 26 qui 
reprSsente I'algorithme sur lequel est base le procede de traitement d'un paquet 
1 0 de donnees asynchrone selon ('invention. 

Cet algorithme est mis en ceuvre au niveau de chaque pont du 

rSseau. 

Les diffSrentes instructions ou etapes de ce procede font partie 
d'un programme informatique stocke dans la memoire ROM de chacun des 
15 ponts du reseau, memoire qui est analogue a la memoire ROM du pont 1226 
represents a la figure 3. 

Comme represents sur la figure 25, un paquet de donnSes 1350 
emis par le pSriphSrique source 1240 comporte des informations d'identification 
du chemin pour ledit paquet et qui sont contenues dans I'ensemble des champs 
20 d'informations 1350a. 

Lorsque le paquet 1 350 est receptionnS au niveau du pont source 
1220, I'unite de calcul CPU dudit pont execute I'algorithme represents a la 
figure 26 et, au cours d'une Stape 1352, vSrifie que le paquet regu est bien un 
paquet du type asynchrone. 
25 Lorsque le paquet de donnees n'est pas un paquet de type 

asynchrone, il est traite au niveau du pont d'une maniere diffSrente de celle 
prSvue par Talgorithme de la figure 26 et le procede prevoit de se placer en 
attente de reception d'un autre paquet. 

Au contraire, dans le cas present, I'etape 1352 est suivie d'une 
30 etape 1354 au cours de laquelle on procede a un test quant a savoir si le 
paquet se situe au niveau d'un pont source. 
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Dans I'exemple represents a la figure 25, le paquet se situe au 
niveau du pont source 1220 et I'etape 1354 est alors suivie d'une etape 1353 au 
cours de laquelle on determine si le paquet est un paquet de type requete. 

Dans la negative, il s'agit d'un paquet de reponse et, au cours de 
5 I'etape suivante 1 355, 1'unite de calcul CPU execute Palgorithme de la figure 1 1 . 

Dans I'affirmative, au cours de I'etape suivante 1356, il est 
precede a la lecture de la valeur de I'index notee fO contenu dans I'ensemble 
des champs d'informations note 1350a du paquet de donnees 1350. 

La valeur de cet index permet ainsi de pointer dans la table de 
10 routage 1260 du pont source 1220 sur I'enregistrement elementaire 1320 
contenu dans cette table. 

On precede alors a une operation d'ecriture dans le paquet 1358 
qui va 6tre emis par le pont source et qui correspond au paquet 1350 apres 
traitement par ledit pont source. 
15 Plus particulierement, on ecrit dans un champ note 1358a du 

paquet 1358 le descripteur de chemin denomme "forward_0" et qui est contenu 
dans le champ 1320a de I'enregistrement elementaire 1320, ainsi que I'index fi 
dans un champ note 1358b dudit paquet. 

Cet index f1 a ete determine precedemment lors de 
20 I'etablissement du chemin et stocke dans I'enregistrement elementaire 1320 au 
niveau du champ 1320b. 

Le paquet 1 358 est alors emis par le pont source sur le reseau en 
direction du pont relais 1226 qu'il atteint apres avoir traverse les ponts 
intermediates 1222 et 1224. 
25 Lorsque le paquet 1358 est reception ne par le pont relais 1226, 

I'unite de calcul de celui-ci execute I'algorithme represents a la figure 26 et 
precede au test de I'etape 1352 qui a deja ete decrit ci-dessus. 

Etant donne que le paquet 1358 est un paquet de type 
asynchrone, alors cette derniere etape est suivie de I'etape 1354 egalement 
30 decrite ci-dessus. 

Comme le paquet se situe au niveau du pont relais 1226, cette 
derniere etape est suivie d'une etape 1360 au cours de laquelle on precede a 
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un test afin de determiner s'il reste des informations d'identification du chemin a 
parcourir, c'est-a-dire si le champ d'informations d'identification du chemin a 
parcourir est vide. 

Ce test est r6alise en detectant la presence d'un marqueur dans le 
5 paquet de donnees. 

II convient de noter que lorsque cette etape est executee au cours 
du transfert du paquet de donnees dans un pont intermediaire tel que les ponts 
1222 et 1224, alors le descripteur de chemin n'est pas complet et cette etape 
est suivie d'une etape 1362 au cours de laquelle on precede a un traitement 
10 approprie dudit paquet de donnees dans le pont intermediaire considere, 
comme decrit en reference a la figure 1 1 . 

Au niveau du pont relais 1226, le champ d'informations 
d'identifications du chemin a parcourir est vide et I'etape 1360 est suivie d'une 
etape 1364. 

15 Lors de cette derniere etape, on precede a un test afin de 

determiner s'il existe dans la table de routage 1262 du pont relais 1226 un 
enregistrement elementaire correspondant a ('information descripteur de chemin 
du paquet de donnees 1358. 

Si cet enregistrement representatif du chemin retour n'existe pas 

20 au niveau de la table de routage, alors I'etape 1364 est suivie d'une etape 1366 
au cours de laquelle on precede a remission d'un paquet d'erreur vers le pont 
source. 

Au contraire, si comme on Fa vu precedemment, le chemin a bien 
ete etabli confomnement a la description faite en reference aux figures 21 a 24, 
25 alors I'etape 1364 est suivie d'une etape 1368 au cours de laquelle on precede 
a un test sur la variable "Bridge Type" afin de determiner si sa valeur est egale 
a 1 ou non. 

Si cette valeur n'est pas egale a 1, alors cela signifie que le 
paquet se situe au niveau d'un pont destination, comme le pont note 1221, et il 
30 est alors precede a un traitement approprie du paquet de donnees en question 
au niveau de ce pont (etape 1370), de la maniere indiquee dans la description 
faite en reference aux figures 9 a 1 1 . 
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Si au contraire, la valeur de la variable "Bridge Type" est egale a 
1 , alors cela signifie que le pont est un pont relais (ce qui est le cas du pont 
1226) et cette etape est alors siiivie d'une etape 1356. 

Lors de cette derniere etape, on precede a une operation de 
5 lecture de la valeur de I'index f1 contenu dans le champ 1358b du paquet 1358 
regu, permettant ainsi de pointer dans la table de routage 1262 sur 
I'enregistrement elementaire correspondant 1314 et ainsi de lire ledit 
enregistrement. 

Au cours de cette meme etape, on procede egalement a une 
10 operation d'ecriture dans le paquet 1370 qui correspond au paquet 1358 apres 
traitement par le pont relais. 

Plus particulierement, les informations representatives du chemin 
a parcourir pour le paquet depuis le premier pont relais 1226 jusqu'au deuxieme 
pont relais 1232, c'est-a-dire le descripteur de chemin denomm6 "forward_1" 
15 sont ecrites dans un champ note 1370a du paquet 1370. 

Ces informations d'identification de chemin pont ete obtenues 
precedemment lors de la description faite en reference aux figures 21 a 24. 

On procede egalement a Pecriture dans un champ note 1370b du 
paquet 1370 de la valeur de I'index f2 determinee egalement lors de 
20 I'etablissement du chemin entre le pont source et le pont destination. 

Ce paquet 1370 traite est ensuite emis par le premier pont relais 
1226 vers le deuxieme pont relais 1232 qu'il atteint apres avoir ete transfere par 
les ponts intermediates 1228 et 1230. 

Dans ce deuxieme pont relais, les etapes de I'algorithme de la 
25 figure 26 qui sont executees sont les mSmes que celles executees lors du 
traitement du paquet 1358 par le pont relais 1226 et il s'agit des etapes 1352, 
1 354, 1 360, 1 364, 1 368 et 1 356. 

Au cours de I'etape 1356, on procede a la lecture de la valeur de 
I'index f2 contenu dans le paquet 1370 afin de pointer, a I'aide de cet index, 
30 dans la table de routage 1264 sur I'enregistrement elementaire correspondant 
note 1308 et Ton procede egalement a la lecture de cet enregistrement. 
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Cet enregistrement contient, dans le champ note 1308a, les 
informations d'identification du chemin a parcourir entre le pont relais 1232 et le 
pont destination 1221, egaiement qualifiees de descripteur de chemin 
denomme "forward_2", ainsi que la valeur de I'index b2 qui sera utilised au 
5 niveau du pont destination. 

Le descripteur de chemin "forward_2" et la valeur de I'index b2 ont 
ete determines precedemment lors de I'etablissement du chemin entre le pont 
source et le pont destination. 

On precede alors a une operation d'ecriture dans le paquet note 
10 1372 et qui correspond au paquet 1370 apres traitement au niveau du pont 
relais 1232. 

Les informations contenues dans le descripteur de chemin 
denomme "forward_2" sont ecrites dans un champ 1372a du paquet 1372 et la 
valeur de I'index b2 est egaiement ecrite dans un champ 1372b de ce meme 
1 5 paquet. 

Le paquet ainsi traite est ensuite 6mis par le deuxieme pont relais 
1232 vers le pont destination 1221 qui se trouve etre le pont suivant (figure 20). 

L'unite de calcul CPU du pont destination 1221, analogue au pont 
1226 represents sur la figure 3, execute I'algorithme de la figure 26 et plus 
20 particulierement les etapes notees 1352, 1354, 1360, 1364, 1366, 1368 et 
1370. 

Les etapes 1352 et 1354 sont identiques a celles decrites 
precedemment lors du traitement des paquets de donnees au niveau des ponts 
relais et ne seront done pas reprises ici. 
25 L'etape 1360 precede a un test afin de determiner si le descripteur 

de chemin du paquet considere est "complet". 

Plus particulierement, il convient de noter que ce test est realise 
en pratique en detectant la presence du marqueur ou troisieme champ 
d'informations dans I'ensemble des champs reserves aux informations 
30 d'identification de chemin. 

Si le marqueur est detecte, cela signifie que le champ 
d'informations d'identification du chemin a parcourir est vide. 
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Lors du transfert d'un paquet de type asynchrone, le test pratiqu6 
a I'etape 1 360 est toujours effectue de cette maniere. 

La description de la detection de ce marqueur qui a ete faite en 
reference aux figures 9 a 1 1 peut etre reprise dans la presente description. 
5 Lorsque les informations contenues dans le descripteur de chemin 

"forward_2" ont ete consommees et que les informations contenues dans le 
descripteur de chemin retour denomme "backward_2" ont ete elaborees, on 
v6rifie, au cours de I'etape suivante 1364, que ce descripteur de chemin 
"backward_2" est bien present dans un enregistrement de la table de routage 
10 1266. 

Dans le cas present, ce descripteur de chemin est present dans 
I'enregistrement elementaire 1267 et plus particulierement dans le champ 
1267a de celui-ci et Ton trouve egalement la valeur de la variable "Bridge Type" 
egale a 0 dans le champ 1267c dudit enregistrement. 

15 Ainsi, I'etape suivante 1368 de i'algorithme de la figure 26 est 

suivie de I'etape 1370 au cours de laquelle un traitement approprie identique a 
celui decrit en reference aux figures 9 a 11 est effectue au niveau du pont 
destination 1221 sur le paquet de donnees recu 1372, et I'index b2 qui etait 
present dans le champ 1372b du paquet de donnees 1372 est alors insure dans 

20 le paquet 1374 correspondant au paquet 1372 apres traitement par le pont de 
destination 1221, et plus particulierement dans I'ensemble des champs 1374a 
reserves aux informations d'identification du chemin dudit paquet. 

Le paquet 1374 est ensuite transfer^ sur le bus de communication 
auquel est relie le pont 1221 et est envoye sur le peripherique destination 1242. 

25 II convient de noter que les ponts relais 1226 et 1232 de la figure 

25 contiennent chacun deux index respectivement bO et f1 pour le pont 1226 et 
b1 etf2 pour le pont 1232. 

Au niveau de chaque pont, Tun des index permet de retrouver les 
informations d'identification du chemin retour permettant de retourner au pont 

30 relais precedent ou au pont source, selon le cas de figure envisage 
("backwardJD" et "backward_1"), et I'autre permet de retrouver les informations 
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^identification du chemin aller jusqu'au prochain pont relais ou jusqu'au pont 
destination, selon le cas de figure envisage ("forward_1" et "forward_2"). 

En revanche, les tables de routage des ponts source et 
destination ne comprennent qu'un index pointant chacun sur les informations 
5 d'identification permettant de retrouver soit le chemin aller jusqu'au prochain 
pont relais, soit le chemin retour jusqu'au dernier pont relais. 

La figure 27 illustre le cheminement d'un paquet de donnees 
- asynchrone de reponse au paquet 1374 precedemment recu (figure 25) a 
travers le reseau de communication selon I'invention note 1200. 

10 L'algorithme repr6sente a la figure 27 et mis en ceuvre au niveau 

de chacun des ponts du reseau reste le meme dans le cas present. 

Le paquet de donnees de n§ponse 1380 comporte un ensemble 
de champs reserves aux informations d'identification du chemin a parcourir par 
le paquet de donnees note 1380a et qui contient I'index b2 precedemment 

1 5 decrit en reference a la figure 25. 

II convient de noter que dans la description faite en reference a la 
figure 27 qui va suivre, on ne reviendra pas sur la description des etapes de 
l'algorithme de la figure 27 qui sont identiques a celles faites en reference a la 
description de la figure 25. 

20 II convient toutefois de noter qu'au niveau de ce pont relais le 

champ d'informations d'identification du chemin a parcourir est vide (marqueur 
detecte) mais que le champ d'informations d'identification du chemin parcouru 
n'est pas complet contrairement a ce qui se passait au niveau des ponts 1226, 
1232 et 1221 lors de remission du paquet asynchrone (figure 25). 

25 L'index b2 contenu dans I'ensemble des champs d'informations 

1380a permet de pointer, au niveau de la table de routage 1266, sur 
I'enregistrement elementaire 1267 dans lequel sont memorisees les 
informations d'identification contenues dans le descripteur de chemin 
"backward_2", permettant au paquet de donnees de parvenir du pont 

30 destination 1221 au pont relais 1232 et la valeur d'index b1 qui permet de 
retrouver au niveau du pont relais 1232 les informations d'identification 



89 



2794918 



contenues dans le descripteur de chemin pour parvenir dudit pont relais au pont 
relais suivant note 1226. 

Les information d'identification contenues dans le descripteur de 
chemin "backward_2" et la valeur de I'index b1 sont respectivement Rentes 
5 dans deux champs d'un paquet de donnees 1382 qui est issu du paquet 1380 
et obtenu apres traitement par le pont destination 1221. 

Plus particulierement, les informations d'identification de chemin 
"backward_2" sont ecrites dans un champ note 1382a, tandis que la valeur de 
I'index b1 est ecrite dans un champ note 1382b. 
10 Ce paquet 1382 est emis sur le reseau et parvient au pont relais 

1232 au niveau duquel la valeur de I'index b1 est lue dans le paquet 1382, ce 
qui permet de pointer dans la table de routage 1264 sur I'enregistrement 
elementaire 1265. 

Cet enregistrement contient le descripteur de chemin dSnomme 
15 "backward_1 " permettant de parvenir du pont relais 1232 jusqu'au pont relais 
1226 et la valeur de I'index bO qui sera utilisee ulterieurement au niveau du pont 
relais 1 226 afin de retrouver le descripteur de chemin permettant de remonter 
jusqu'au pont source 1220. 

Les informations d'identification contenues dans le descripteur de 
20 chemin "backward_1" et la valeur de I'index bO sont respectivement ecrites 
dans deux champs du paquet de donnees 1384 qui est obtenu a partir du 
paquet 1382 apres traitement dans le pont relais 1232 et sont respectivement 
notes 1384a et 1384b. 

Ce paquet 1384 est emis par le pont relais 1232 et parvient au 
25 pont relais 1226 au niveau duquel la valeur de I'index bO dudit paquet 1384 est 
lue et permet de pointer dans la table de routage 1262 sur I'enregistrement 
elementaire 1263. 

Cet enregistrement elementaire contient le descripteur de chemin 
denomme "backward_0" permettant de parvenir du pont relais 1226 au pont 
30 source 1220 et la valeur de I'index a 0. 

Les informations d'identification contenues dans le descripteur de 
chemin "backward_0" et la valeur nulle de I'index sont ecrites dans deux 
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champs du paquet 1386 qui est obtenu a partir du paquet 1384 apres traitement 
dans le pont relais 1226 et sont respectivement notes 1386a et 1386b. 

Lorsque le paquet 1386 parvient au pont source 1220, le test de 
I'etape 1354 de ralgorithme de la figure 26 conduit a I'etape suivante 1353 au 
5 cours de laquelle on determine s'il s'agit d'un paquet de requeue. 

Si c'est un paquet de requete, I'etape 1 353 est suivie de I'etape 
1 356 deja decrite plus haut. 

Au contraire si, comme dans le cas present (paquet reponse), il ne 
s'agit pas d'un paquet de requete, alors I'etape 1353 est suivie d'une etape 
10 1355 au cours de laquelle un traitement approprie dudit paquet est effectue de 
maniere identique a la description faite en reference a la figure 1 1 . 

II convient de noter que I'index present dans chaque paquet de 
donnees de type asynchrone, comme represents sur les figures 25 et 27, peut 
etre contenu soit dans le champ note "pri" 85 du paquet de donnees represente 
15 a la figure 2, soit dans un champ denomme "extended-tcode" non represente 
de ce meme paquet. 

II convient de noter que le champ "pri" comporte quatre bits qui ne 
sont pas toujours utilises selon I'environnement envisage. 

Par exemple, dans un environnement cable qui est defini dans le 
20 document "P1 394, Draft 8.ov2, July 7, 1 995", ce champ n'est pas utilise. 

Dans ce document, il et notamment expliqu6 que la topologie 
physique d'un environnement cable est un reseau non cyclique pourvu de 
branches finies et d'extensions. 

II convient egalement de noter que le champ "extended-tcode" est 
25 partiellement utilise : sur les 16 bits de ce champ seuls les quatre bits de poids 
faibles sont utilises, laissant ainsi 12 bits vacants. 

Toutefois, ('utilisation d'un tel champ pour stacker la valeur de 
I'index impose de transformer tout paquet de donnees de type "data quadlet", 
c'est-a-dire contenant quatre octets de donnees en paquet de donnees de type 
30 "data block", c'est-a-dire contenant n octets de donnees. 

Ces definitions ressortent de la norme IEEE 1394-95 
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REVINDICATIONS 

1. Procede de traitement d'un paquet de donnees dans un reseau 
de communication comportant deux ponts dits d'extremites separes I'un de 
5 I'autre par au moins un pont dit intermediaire, chacun desdits ponts 
interconnectant au moins deux parties dudit reseau, ledit paquet comportant au 
moins un champ d'informations de longueur predeterminee reserve a des 
informations d'identification d'un chemin dans le r6seau, caracteris6 en ce que 
ledit procede comporte les etapes suivantes : 

10 -recevoir ledit paquet de donnees par un pont interm6diaire 

appele pont relais et au niveau duquel le champ d'informations d'identification 
du chemin parcouru par ledit paquet contient un nombre maximum 
d'informations d'identification dudit chemin et/ou le champ d'informations 
d'identification du chemin a parcourir par ledit paquet est vide, 

15 -faire intervenir, d'une part, une premiere zone memoire (1265 ; 

1314) dans ledit pont relais et qui comporte un champ d'informations 
d'identification d'un chemin entre ledit pont relais et un autre pont et, d'autre 
part, au moins un index (b1, f1) dans le paquet de donnees et qui permet de 
retrouver ladite zone memoire dans ledit pont relais. 

20 2. Procede selon la revendication 1, caracterise en ce qu'il 

comporte les etapes suivantes : 

-allocation de ladite zone memoire et recuperation dudit index 

(b1), 

-ecriture dans ladite zone memoire des informations 
25 d'identification du chemin parcouru par le paquet depuis I'autre pont (1226 ; 
1 221 ) jusqu'audit pont relais (1 232), 

- ecriture dudit index (b1 ) dans le paquet. 

3. Procede selon la revendication 1 ou 2, caracterise en ce qu'il 
comporte une etape d'ecriture dans ladite zone memoire d'un autre index (bO) 
30 permettant de retrouver ulterieurement dans I'autre pont appele egalement pont 
relais (1226) une zone memoire (1263) comportant des informations 
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d'identification du chemin parcouru par le paquet pour parvenir jusqu'a cet autre 
pontrelais (1226). 

4. Proced6 selon Tune des revendications 1 a 3, caracteris6 en ce 
qu'il comporte une 6tape d'utilisation de I'index (b1) ecrit dans le paquet pour 

5 retrouver dans ledit pont relais (1232) les informations d'identification du chemin 
a parcourir par ledit paquet depuis ledit pont relais jusqu'a I'autre pont (1226). 

5. Proced6 selon la revendication 4, caracteris6 en ce que Tetape 
d'utilisation de I'index (b1) ecrit dans le paquet permet egalement de retrouver 
I'index (bO) qui sera utilise ultSrieurement dans I'autre pont (1226) pour 

10 retrouver la zone m6moire (1263) comportant des informations d'identification 
du chemin a parcourir a partir de cet autre pont. 

6. Precede selon la revendication 5, caracteris6 en ce qu'il 
comporte une etape d'ecriture de I'index (bO) dans le paquet a la place de 
I'index (b1). 

1 5 7. Proc6de selon Tune des revendications 1 a 6 , caracteris6 en 

ce qu'il comporte une etape d'ecriture, dans le paquet, d'informations 
d'identification du chemin a parcourir a la place d'informations d'identification du 
chemin parcouru. 

8. Procede selon Tune des revendications 1 a 7, caracteris6 en ce 
20 qu'il comporte les 6tapes suivantes : 

-allocation d'une deuxieme zone m6moire (1308) dans ledit pont 
relais (1232) reference par un autre index (f2) donne\ 

-ecriture dans ladite deuxieme zone memoire d'informations 
d'identification du chemin parcouru par le paquet depuis I'autre pont (1221) 
25 jusqu'audit pont relais (1232), 

- ecriture dudit index (f2) dans le paquet. 

9. Procede selon la revendication 8, caracteris6 en ce qu'il 
comporte une Stape d'ecriture dans la deuxieme zone m6moire (1308) du pont 
relais (1232) d'un index (b2) permettant de retrouver ulterieurement dans I'autre 

30 pont (1221) une zone memoire (1267) comportant des informations 
d'identification du chemin parcouru par le paquet depuis ledit pont relais (1232) 
jusqu'audit autre pont (1221). 
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10. Procede selon Tune des revendications 1 a 9, caracteris6 en 
ce qu'il comporte une etape d'utilisation de I'index (f1) ecrit dans le paquet pour 
retrouver dans la zone memoire (1314) dudit pont relais les informations 
d'identification du chemin a parcourir depuis ledit pont relais (1226) jusqu'a un 

5 autre pont (1232). 

11. Procede selon la revendication 10, caracterise en ce que 
I'etape d'utilisation de I'index (f1) ecrit dans le paquet permet egalement de 
retrouver un deuxieme index (f2) qui sera utilise ulterieurement dans I'autre pont 
appele pont relais (1232) pour retrouver une zone memoire (1308) comportant 

10 des informations d'identification du chemin a parcourir a partir de cet autre pont 
relais. 

1 2. Procede selon la revendication 1 1 , caracterise en ce qu'il 
comporte une etape d'ecriture de I'index (f2) dans le paquet a la place de I'index 
<f1). 

15 13. Procede selon I'une des revendications 1 a 3, caracterise en 

ce que le paquet de donnees est un paquet de diffusion. 

14. Procede selon I'une des revendications 1, 4 a 9, caracterise 
en ce que le paquet de donnees est un paquet de r6ponse a un paquet dit de 
diffusion. 

20 15. Procede selon I'une des revendications 1, 10, 11, 12, 

caracterise en ce que le paquet de donnees est un paquet asynchrone. 

16. Procede selon I'une des revendications 1 a 15, caracterise en 
ce que ledit paquet de donnees comporte au moins deux champs 
d'informations dits d'identification du chemin respectivement a parcourir et 

25 parcouru par ledit paquet de donnees, lesdits au moins deux champs 
d'informations ayant chacun une longueur donnee, ledit procede comportant les 
etapes suivantes lors du transfert dudit paquet de donnees a travers un pont : 

- suppression d'au moins une premiere information d'au moins un 
premier champ d'informations, reduisant ainsi la longueur dudit premier champ 

30 d'informations d'une longueur correspondant a celle de ladite premiere 
information, 
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- ajout d'au moins une deuxieme information dans au moins un 
deuxieme champ d'informations, augmentant ainsi la longueur dudit deuxieme 
champ d'informations d'une longueur correspondant a celle de ladite deuxieme 
information. 

5 17. Procede selon la revendication 16, caracterise en ce qu'un 

pont comportant au moins deux equipements d'interconnexion relies chacun 
auxdites au moins deux parties du reseau, au moins un identificateur est affects 
a chacun desdits au moins deux equipements d'interconnexion. 

18. Procede selon la revendication 17, caracterise en ce que 
10 lesdits premier et deuxieme champs d'informations contiennent des 
informations relatives audit au moins un identificateur de chaque equipement 
d'interconnexion du ou des ponts disposes sur le chemin du paquet de donnees 
dans le reseau. 

19. Procede selon la revendication 18, caracteris§ en ce que 
15 ledit premier champ d'informations contient des informations relatives audit au 
moins un identificateur de chaque equipement d'interconnexion sur le chemin a 
parcourir par le paquet de donnees dans le reseau. 

20. Procede selon la revendication 17, caracterise en ce que 
ladite au moins une premiere information supprimee dudit au moins un premier 

20 champ d'informations correspond audit au moins un identificateur de chaque 
equipement d'interconnexion du pont qui est reli6 a la partie du reseau par 
laquelle le paquet de donnees parvient audit pont. 

21. ProcedS selon Tune des revendications 17 a 20, caract§ris6 
en ce que ledit deuxieme champ d'informations contient des informations 

25 relatives audit au moins un identificateur de chaque equipement 
d'interconnexion du ou des ponts disposes sur le chemin parcouru par le 
paquet de donnees dans le reseau. 

22. Procede selon la revendication 21, caracterise en ce que 
ladite au moins une deuxieme information ajoutee audit au moins un deuxieme 

30 champ d'informations correspond audit au moins un identificateur de 
I'equipement d'interconnexion pont qui est relie a la partie du reseau par 
laquelle le paquet de donnees quitte ledit pont. 
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23. Procede selon I'une des revendications 16 a 22, caracterise 
en ce que le paquet de donnees comporte un troisieme champ d'informations 
dit marqueur qui delimite les premier et deuxieme champs d'informations I'un 
par rapport a I'autre. 

5 24. Procede selon les revendications 17 et 23, caracterise en ce 

que le marqueur a une longueur au moins egale au nombre de bits necessaire 
pour coder un identificateur d'equipement d'interconnexion d'un pont dans I'un 
des champs d'informations. 

25. Procede selon la revendication 24, caracterise en ce qu'il 
10 comporte, lors du transfert dudit paquet de donnees a travers un pont, une 

etape de decalage des premier, deuxieme et troisieme champs d'informations 
entre les etapes de suppression et d'ajqut d'informations. 

26. Procede selon I'une des revendications 24 a 25, caracterise 
en ce que la longueur totale des premier, deuxieme et troisieme champs est 

1 5 fixe. 

27. Procede selon I'une des revendications 1 a 26, caracterise en 
ce que chaque partie du reseau a laquelle est connectee un pont comporte un 
bus de communication. 

28. Procede selon la revendication 27, caracterise en ce que le 
20 bus de communication est du type conforme a la norme IEEE 1394. 

29. Procede d'emission d'un paquet de donnees dans un reseau 
de communication entre deux ponts dits d'extr6mites separes I'un de I'autre par 
plusieurs ponts dits intermediates, chacun desdits ponts interconnectant au 
moins deux parties dudit reseau, ledit paquet comportant au moins un champ 

25 d'informations de longueur predeterminee reserve a des informations 
d'identification d'un chemin dans le reseau, caracterise en ce que ledit procede 
comporte une etape d'emission dudit paquet. de donnees a partir d'un premier 
pont d'extremite, ledit au moins un champ contenant des informations 
d'identification du chemin a parcourir depuis ledit premier pont d'extremite 

30 jusqu'a un pont intermediate appele pont relais et au niveau duquel le champ 
d'informations d'identification du chemin parcouru par ledit paquet contient un 
nombre maximum d'informations d'identification dudit chemin et/ou le champ 
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d'informations d'identification du chemin a parcourir par ledit paquet est vide, 
ledit paquet de donnees comportant egalement un index permettant de 
retrouver au niveau dudit pont relais des informations representatives du 
chemin a parcourir depuis ledit pont relais jusqu'au deuxieme pont d'extremite. 
5 30. Precede selon la revendication 29 caracterise en ce que le 

paquet de donnees est un paquet dit de reponse a un paquet dit de diffusion 
emis par le deuxieme pont d'extremite. 

31. Procede selon la revendication 30, caracterise en ce que les 
informations d'identification du chemin a parcourir depuis ledit premier pont 

10 d'extremite jusqu'au pont relais sont obtenues a partir des informations 
d'identification du chemin parcouru par le paquet de donnees de diffusion 
depuis le pont relais jusqu'au premier pont d'extremite. 

32. Procede selon la revendication 30 ou 31, caracteris6 en ce 
que les informations d'identification du chemin a parcourir depuis le pont relais 

15 jusqu'au deuxieme pont d'extremite sont obtenues a partir d'un index 
permettant de retrouver au niveau dudit pont relais les informations 
representatives du chemin parcouru depuis le deuxieme pont d'extremite 
jusqu'au pont relais. 

33. Procede selon la revendication 29, caracterise en ce que le 
20 premier pont est appele pont source et le deuxieme pont est appele pont 

destination. 

34. Procede selon Tune des revendications 29 a 32, caract6ris6 
en ce que le premier pont est appele pont destination et le deuxieme pont est 
appele pont source. 

25 35. Procede de reception d'un paquet de donnees emis sur un 

reseau de communication entre deux ponts dits d'extremites separes Tun de 
I'autre par piusieurs ponts dits intermediaires, chacun desdits ponts 
interconnectant au moins deux parties dudit reseau, ledit paquet comportant au 
moins un champ d'informations de longueur predeterminee reserve a des 

30 informations d'identification d'un chemin dans le reseau, caracterise en ce que 
ledit procede comporte une etape de reception au niveau d'un premier pont 
d'extremite dudit paquet de donnees emis par un deuxieme pont d'extremite, 
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ledit au moins un champ contenant des informations d'identification du chemin 
parcouru depuis un pont intermediate appele pont relais et au niveau duquel le 
champ d'informations d'identification du chemin parcouru par ledit paquet 
contient un nombre maximum d'informations d'identification dudit chemin et/ou 
le champ d'informations d'identification du chemin a parcourir par ledit paquet 
est vide, ledit paquet comportant egalement un index permettant de retrouver 
au niveau dudit pont relais des informations representatives du chemin 
parcouru depuis le deuxieme pont jusqu'audit pont relais. 

36. Procede selon la revendication 35, caracterise en ce que le 
paquet de donnees est un paquet de diffusion. 

37. Procede selon la revendication 35, caracteris6 en ce que le 
paquet de donnees est un paquet de reponse a un paquet dit de diffusion emis 
par le premier pont d'extremite. 

38. Procede selon la revendication 37, caracterise en ce que le 
paquet de reponse comporte la totalite des informations representatives du 
chemin a parcourir depuis le premier pont d'extremite jusqu'au deuxieme pont 
d'extremite, celles-ci etant obtenues a partir, d'une part, des informations 
d'identification du chemin parcouru depuis le pont relais jusqu'au premier pont 
d'extremite et, d'autre part, de I'index. 

39. Procede selon la revendication 36, caracterise en ce que le 
premier pont est appele pont destination et le deuxieme pont est appele pont 
source. 

40. Procede selon I'une des revendications 37 a 38, caracterise 
en ce que le premier pont est appele pont source et le deuxieme pont est 
appele pont destination. 

41. Dispositif de traitement d'un paquet de donnees dans un 
reseau de communication comportant deux ponts dits d'extremites separes I'un 
de I'autre par au moins un pont dit intermediate, chacun desdits ponts 
interconnectant au moins deux parties dudit reseau, ledit paquet comportant au 
moins un champ d'informations de longueur predeterminee reserve a des 
informations d'identification d'un chemin dans le reseau, caracterise en ce que 
ledit dispositif comporte : 
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- des moyens pour recevoir ledit paquet de donnees par un pont 
intermediate appeie pont relais et au niveau duquel le champ d'informations 
d'identification du chemin parcouru par ledit paquet contient un nombre 
maximum d'informations d'identification dudit chemin et/ou le champ 

5 d'informations d'identification du chemin a parcourir par ledit paquet est vide, 

- des moyens pour faire intervenir, d'une part, une premiere zone 
m6moire (1265 ; 1314) dans ledit pont relais et qui comporte un champ 
d'informations d'identification d'un chemin entre ledit pont relais et un autre pont 
et, d'autre part, au moins un index (b1, f1) dans le paquet de donn6es et qui 

10 permet de retrouver ladite zone memoire dans ledit pont relais. 

42. Dispositif selon la revendication 41, caracteris6 en ce qu'il 

comporte : 

- des moyens d'allocation de ladite zone memoire et recuperation 
dudit index (b1), 

15 -des moyens d'ecriture dans ladite zone memoire des 

informations d'identification du chemin parcouru par le paquet depuis I'autre 
pont (1226 ; 1221) jusqu'audit pont relais (1232), 

- des moyens d'ecriture dudit index (b1) dans le paquet. 

43. Dispositif selon la revendication 41 ou 42, caracteris6 en ce 
20 qu'il comporte des moyens d'ecriture dans ladite zone m6moire d'un autre index 

(bO) permettant de retrouver ulterieurement dans I'autre pont appele 6galement 
pont relais (1226) une zone memoire (1263) comportant des informations 
d'identification du chemin parcouru par le paquet pour parvenir jusqu'a cet autre 
pont relais (1226). 

25 44. Dispositif selon I'une des revendications 41 a 43, caracteris6 

en ce qu'il comporte des moyens pour retrouver dans ledit pont relais (1232) les 
informations d'identification du chemin a parcourir par ledit paquet depuis ledit 
pont relais jusqu'a I'autre pont (1226), a partir de I'index (b1) 6crit dans le 
paquet. 

30 45. Dispositif selon la revendication 44, caracterise en ce qu'il 

comporte des moyens pour retrouver dans ledit pont relais (1232), a partir de 
I'index (b1) ecrit dans le paquet, I'index (bO) qui sera utilise ulterieurement dans 
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I'autre pont (1226) pour retrouver la zone m6moire (1263) comportant des 
informations d'identification du chemin a parcourir a partir de cet autre pont. 

46. Dispositif selon la revendication 45, caracterise en ce qu'il 
comporte des moyens d'ecriture de I'index (bO) dans le paquet a la place de 

5 I'index (b1). 

47. Dispositif selon Tune des revendications 41 a 46, caracterise 
en ce qu'il comporte des moyens d'ecriture, dans le paquet, d'informations 
d'identification du chemin a parcourir a la place d'informations d'identification du 
chemin parcouru. 

10 48. Dispositif selon Tune des revendications 41 a 47, caracteris6 

en ce qu'il comporte : 

-des moyens d'allocation d'une deuxieme zone memoire (1308) 
dans ledit pont relais (1232) reference par un autre index (f2) donne, 

-des moyens d'ecriture dans ladite deuxieme zone m6moire 
15 d'informations d'identification du chemin parcouru par le paquet depuis I'autre 
pont (1221) jusqu'audit pont relais (1232), 

- des moyens d'ecriture dudit index (f2) dans le paquet. 

49. Dispositif selon la revendication 48, caracterise en ce qu'il 
comporte des moyens d'ecriture dans la deuxieme zone memoire (1308) du 

20 pont relais (1232) d'un index (b2) permettant de retrouver ulterieurement dans 
I'autre pont (1221) une zone memoire (1267) comportant des informations 
d'identification du chemin parcouru par le paquet depuis ledit pont relais (1232) 
jusqu'audit autre pont (1221). 

50. Dispositif selon I'une des revendications 41 a 49, caracterise 
25 en ce qu'il comporte des moyens pour retrouver dans la zone memoire (1314) 

dudit pont relais les informations d'identification du chemin a parcourir depuis 
ledit pont relais (1226) jusqu'a un autre pont (1232), a partir de I'index (f1) ecrit 
dans le paquet. 

51 . Dispositif selon la revendication 50, caracterise en ce qu'il 
30 comporte des moyens pour de retrouver dans la zone memoire (1314), a partir 
de I'index (f1) ecrit dans le paquet, un deuxieme index (f2) qui sera utilise 
ulterieurement dans I'autre pont appele pont relais (1232) pour retrouver une 
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zone memoire (1308) comportant des informations d'identification du chemin a 
parcourir a partir de cet autre pont relais. 

52. Dispositif selon la revendication 51, caracterise en ce qu'il 
comporte des moyens d'ecriture de I'index (f2) dans le paquet a la place de 
I'index (f1). 

53. Dispositif selon Tune des revendications 41 a 43, caracterise 
en ce que le paquet de donnees est un paquet de diffusion. 

54. Dispositif selon I'une des revendications 41, 44 a 49, 
caracterise en ce que le paquet de donnees est un paquet de reponse a un 
paquet dit de diffusion. 

55. Dispositif selon I'une des revendications41, 50, 51, 52, 
caracterise en ce que le paquet de donnees est un paquet asynchrone. 

56. Dispositif selon I'une des revendications 41 a 55, caracteris6 
en ce qu'il comporte une zone memoire (1265 ; 1314) referencee par un index 
(bO, b1, f1) et comportant, d'une part, des informations d'identification du 
chemin parcouru par le paquet depuis I'autre pont (1220 ; 1226 ; 1221) 
jusqu'audit pont relais (1226 ; 1232) et, d'autre part, un index (bO, f2) permettant 
de retrouver ulterieurement dans ledit autre pont une zone memoire (1263) 
comportant des informations d'identification du chemin parcouru par le paquet 
pour parvenir jusqu'a cet autre pont. 

57. Dispositif selon I'une des revendications 41 a 56, caracterise 
en ce qu'il comporte une zone memoire (1314 ; 1308) referencee par un index 
(f2) comportant, d'une part, des informations d'identification du chemin a 
parcourir par le paquet depuis ledit pont relais (1226 ; 1232) jusqu'a I'autre pont 
(1232 ; 1221) et, d'autre part, un index (b2) permettant de retrouver 
ulterieurement dans cet autre pont des informations d'identification du chemin a 
parcourir par le paquet depuis cet autre pont jusqu'a un deuxieme autre pont 
(1221 ; 1232). 

58. Dispositif selon I'une des revendications 41 a 57, caracterise 
en ce que ledit paquet de donnees comportant au moins deux champs 
d'informations dits d'identification du chemin respectivement a parcourir et 
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parcouru par ledit paquet de donnees, lesdits deux champs d'information ayant 
chacun une longueur donnee, ledit dispositif comportant : 

-des moyens de suppression d'au moins une premiere 
information d'au moins un premier champ d'informations, reduisant ainsi la 
5 longueur dudit premier champ d'informations d'une longueur correspondant a 
celle de ladite premiere information, 

- des moyens d'ajout d'au moins une deuxieme information dans 
au moins un deuxieme champ d'informations, augmentant ainsi la longueur 
dudit deuxieme champ d'informations d'une longueur correspondant a celle de 

10 ladite deuxieme information. 

59. Dispositif selon la revendication 58, caracterise en ce qu'un 
pont comportant au moins deux equipements d'interconnexion relies chacun 
auxdites au moins deux parties du reseau, au moins un identificateur est affects 
a chacun desdits au moins deux equipements d'interconnexion. 

15 60. Dispositif selon I'une des revendications 58 a 59, caract6ris6 

en ce que lesdits premier et deuxieme champs d'informations contiennent des 
informations relatives audit au moins un identificateur de chaque 6quipement 
d'interconnexion ou "portal" du ou des ponts disposes sur le chemin du paquet 
de donnees dans le reseau. 

20 61. Dispositif selon I'une des revendications 58 a 60, caract£ris6 

en ce que le paquet de donnees comporte un troisieme champ d'informations 
dit marqueur qui delimite les premier et deuxieme champs d'informations I'un 
par rapport a I'autre. 

62. Dispositif selon la revendication 61, caracteris6 en ce qu'il 
25 comporte des moyens de decalage des premier, deuxieme et troisieme champs 

d'informations. 

63. Dispositif selon la revendication 61 ou 62, caracterise en ce 
que la longueur totale des premier, deuxieme et troisieme champs est fixe. 

30 64. Dispositif d'emission d'un paquet de donnees dans un reseau 

de communication entre deux ponts dits d'extremites separes I'un de I'autre par 
plusieurs ponts dits intermediates, chacun desdits ponts interconnectant au 
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moins deux parties dudit reseau, ledit paquet comportant au moins un champ 
d'informations de longueur predeterminee reserve a des informations 
d'identification d'un chemin dans le reseau, caracterise en ce que ledit dispositif 
comporte des moyens d'emission dudit paquet de donnees a partir d'un premier 
5 pont d'extremite, ledit au moins un champ contenant des informations 
d'identification du chemin a parcourir depuis ledit premier pont d'extremite 
jusqu'a un pont intermediaire appele pont relais et au niveau duquel le champ 
d'informations d'identification du chemin parcouru contient un nombre maximum 
d'informations d'identification dudit chemin et/ou le champ d'informations 
10 d'identification du chemin a parcourir est vide, ledit paquet de donnees 
comportant egalement un index permettant de retrouver au niveau dudit pont 
relais des informations representatives du chemin a parcourir depuis ledit pont 
relais jusqu'au deuxieme pont d'extremite. 

65. Dispositif selon la revendication 64, caracterise en ce que le 
15 paquet de donnees est un paquet dit de reponse a un paquet dit de diffusion 

emis par le deuxieme pont d'extremite. 

66. Dispositif de reception d'un paquet de donnees emis sur un 
reseau de communication entre deux ponts dits d'extremites separes I'un de 
I'autre par plusieurs ponts dits intermediates, chacun desdits ponts 

20 interconnectant au moins deux parties dudit reseau, ledit paquet comportant au 
moins un champ d'informations de longueur predeterminee reserv6 a des 
informations d'identification d'un chemin dans le reseau, caracterise en ce que 
ledit dispositif comporte des moyens de reception au niveau d'un premier pont 
d'extremite dudit paquet de donnees emis par un deuxieme pont d'extremite, 

25 ledit au moins un champ contenant des informations d'identification du chemin 
parcouru depuis un pont intermediaire appele pont relais et au niveau duquel le 
champ d'informations d'identification du chemin parcouru contient un nombre 
maximum d'informations d'identification dudit chemin et/ou le champ 
d'informations d'identification du chemin a parcourir est vide, ledit paquet 

30 comportant egalement un index permettant de retrouver au niveau dudit pont 
relais des informations representatives du chemin parcouru depuis le deuxieme 
pont jusqu'audit pont relais. 
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67. Dispositif selon la revendication 66, caracterise en ce que le 
paquet de donnees est un paquet de diffusion. 

68. Dispositif selon la revendication 66, caracterise en ce que le 
paquet de donnees est un paquet de reponse a un paquet dit de diffusion emis 

5 par le premier pont d'extremite. 

69. Dispositif selon la revendication 68, caracterise en ce que le 
paquet de reponse comporte la totalite des informations representatives du 
chemin a parcourir depuis le premier pont d'extremite jusqu'au deuxieme pont 
d'extremite, celles-ci etant obtenues a partir, d'une part, des informations 

10 d'identification du chemin parcouru depuis le pont relais jusqu'au premier pont 
d'extremite et, d'autre part, de I'index. 

70. Pont relais d'un r6seau de communication dispose entre deux 
ponts dits d'extremites et interconnectant au moins deux parties dudit reseau de 
communication, caracterise en ce qu'il comporte un dispositif de traitement d'un 

15 paquet de donnees selon Tune des revendications 41 a 63. 

71. Pont d'extremite d'un reseau de communication 
interconnectant au moins deux parties dudit reseau de communication, 
caracterise en ce qu'il comporte un dispositif d'emission d'un paquet de 
donnees selon I'une des revendications 64 a 65 et/ou un dispositif de reception 

20 d'un paquet de donnees selon Tunes des revendications 66 a 69. 

72. Appareil de traitement de donnees d'un reseau de 
communication, caracterise en ce qu'il comporte un dispositif de traitement d'un 
paquet de donnees selon I'une des revendications 41 a 43. 

73. Appareil de traitement de donnees d'un reseau de 
25 communication, caracterise en ce qu'il comporte un dispositif d'emission d'un 

paquet de donnees selon I'une des revendications 64 a 65 et/ou un dispositif de 
reception d'un paquet de donnees selon Tunes des revendications 66 a 69. 

74. Appareil de traitement de donnees, caracterise en ce qu'il 
comporte un pont conforme a Tune des revendications 70 a 71. 

30 75. Appareil selon la revendication 74, caracterise en ce que ledit 

appareil est une imprimante. 
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76. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est un serveur. 

77. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est un ordinateur. 

5 78. Appareil selon la revendication 74, caracteris6 en ce que ledit 

appareil est un telecopieur. 

79. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est un scanner. 

80. Appareil selon la revendication 74, caracterise en ce que ledit 
10 appareil est un magnetoscope. 

81. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est un decodeur. 

82. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est un televiseur. 

15 83. Appareil selon la revendication 74, caracterise en ce que ledit 

appareil est une camescope. 

84. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est une camera numerique. 

85. Appareil selon la revendication 74, caracterise en ce que ledit 
20 appareil est un appareil photographique numerique. 

86. Reseau de communication comportant au moins deux parties 
interconnects par au moins un pont, caracterise en ce que ledit pont est 
conforme a Tune des revendications 70 a 71. 

87. Reseau de communication, caracterise en ce que ledit reseau 
25 comporte un appareil de traitement de donnees selon I'une des revendications 

72 a 85. 
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